Gambatte 0.5.0-wip2 released

[sinamas]

I can't configure the keys... the value is almost instantly overwritten with this:

*snip*

Even unplugging the mouse doesn't help. (WinXP SP3, Logitech mouse

Did you try the newest SVN snapshot? It keeps a map of joystick axis states, so only changes that make the axis value go from one side of a threshold to the other are recorded.

Does this joystick device show up in the windows control panel section for joystick devices? If so it may be possible to disable it at least. (Frankly, using a mouse as a joystick device doesn't seem all that useful to me anyway.)

[creaothceann]

I'd forgotten that my joystick was still connected. *facepalm*

Now it works.

[Nach]

For GCC 4.3:

Code: Select all

Index: libgambatte/src/file/file_zip.cpp
===================================================================
--- libgambatte/src/file/file_zip.cpp   (revision 154)
+++ libgambatte/src/file/file_zip.cpp   (working copy)
@@ -19,6 +19,8 @@

 #include "file.h"

+#include <cstring>
+
 namespace zlib {
 #include "unzip/unzip.h"
 }

When compiling now, I'm noticing hundreds of warnings about ambiguities in bit manipulation.

For some reason with latest SVN, the colors in game are completely wrong.

I'm not using any special palette. Turning on HQ2x makes the whole screen pink.

[franpa]

you should use alt printscreen

[Nach]

you should use alt printscreen

What? And ruin my recursive effect of post data in the post data?

[MisterJones]

you should use alt printscreen

how come I wasn't informed of the existence of said function? I demand an explanation!

[adventure_of_link]

you should use alt printscreen

What? And ruin my recursive effect of post data in the post data?

Besides, you use ksnapshot.

[Nach]

you should use alt printscreen

What? And ruin my recursive effect of post data in the post data?

Besides, you use ksnapshot.

That I do, how could you tell?

[adventure_of_link]

for one, alt+printscreen is windows (although to be fair some linux distros have that combo bound to the ksnapshot program)

next you use linux.

[Nach]

for one, alt+printscreen is windows (although to be fair some linux distros have that combo bound to the ksnapshot program)

next you use linux.

Alt+Printscreen works just fine here. But then I have to open up a painting program, paste, and save.

I find it easier to just load up KSnapshot, grap something, and hit save.

You still didn't answer though how you knew it was KSnapshot.

[grinvader]

I'm totally using Ksnapshot when I press alt+printscreen, because i'm on leenoox

ITT AoL knows shit.

Side note: fuck KDE.

[sinamas]

For GCC 4.3:

Code: Select all

Index: libgambatte/src/file/file_zip.cpp
===================================================================
--- libgambatte/src/file/file_zip.cpp   (revision 154)
+++ libgambatte/src/file/file_zip.cpp   (working copy)
@@ -19,6 +19,8 @@

 #include "file.h"

+#include <cstring>
+
 namespace zlib {
 #include "unzip/unzip.h"
 }

When compiling now, I'm noticing hundreds of warnings about ambiguities in bit manipulation.

For some reason with latest SVN, the colors in game are completely wrong.

I'm not using any special palette. Turning on HQ2x makes the whole screen pink.

You mean to say you don't appreciate the new auto-coloring of DMG games?
Thanks. I'll have a look at it as soon as I'm back on a decent *nix setup. I'm guessing it's either related to GCC 4.3 strictness or 64-bit specific.

I've been busy working on a general real-time audio resampler, reading hundreds of pages of DSP theory. I'll probably use a multi-stage approach to deal with high resampling ratios, as is the case with the Game Boy, meaning I use faster low-pass filters with slower roll-off initially to decimate down to a rate more suitable for slower approaches. I'll probably add options for quality since audio resampling can easily become the main performance bottle-neck, especially since I pretty much treat the Game Boy as a system with 2 MHz sample rate.

I decided to go for this rather than the more specific band-limited synthesis approach, mainly becuase I wanted something general that could be used for other systems/situations (possibly as part of a more general multi-media framework). While band-limited synthesis generally produces excellent results for typical PSGs there are some minor weaknesses, which admittedly can either be worked around or are uncommon enough to be neglible, and it's possible to get pretty close in quality (at the expence of performance) using a more general resampling approach. I'll consider adding bandlimited sound synthesis as an option later on though.

[adventure_of_link]

Alt+Printscreen works just fine here. But then I have to open up a painting program, paste, and save.

So that combination even works in Linux, regardless if KSnapshot is bound to it... interesting. I'll have to try it.

I find it easier to just load up KSnapshot, grap something, and hit save.

I concur.

You still didn't answer though how you knew it was KSnapshot.

maybe it was just a guess but seriously though, that's a windows FF background (or at least some mockup of one) with a gambatte window in it.

ITT AoL knows shit.

fuck you

[creaothceann]

2 MHz sample rate

[Nach]

that's a windows FF background (or at least some mockup of one) with a gambatte window in it.

No. I take it you don't know what Seamonkey looks like? Even in Linux.

[odditude]

that's a windows FF background (or at least some mockup of one) with a gambatte window in it.

No. I take it you don't know what Seamonkey looks like? Even in Linux.

Even FF will look like that if you have those fonts installed - I had that on my old Kubuntu 6.06 box.

[adventure_of_link]

No. I take it you don't know what Seamonkey looks like? Even in Linux.

I don't use Seamonkey so I wouldn't know.

I'm mostly a firefox guy.

[mudlord]

I've been busy working on a general real-time audio resampler, reading hundreds of pages of DSP theory. I'll probably use a multi-stage approach to deal with high resampling ratios, as is the case with the Game Boy, meaning I use faster low-pass filters with slower roll-off initially to decimate down to a rate more suitable for slower approaches. I'll probably add options for quality since audio resampling can easily become the main performance bottle-neck, especially since I pretty much treat the Game Boy as a system with 2 MHz sample rate.

I decided to go for this rather than the more specific band-limited synthesis approach, mainly becuase I wanted something general that could be used for other systems/situations (possibly as part of a more general multi-media framework). While band-limited synthesis generally produces excellent results for typical PSGs there are some minor weaknesses, which admittedly can either be worked around or are uncommon enough to be neglible, and it's possible to get pretty close in quality (at the expence of performance) using a more general resampling approach. I'll consider adding bandlimited sound synthesis as an option later on though.

Tried looking through blargg's notes and source code for ideas?

[Nach]

sinamas:

Congrads on the Save State support. I didn't do too many tests on it, but what I did test seems to be working, nice job

[sinamas]

Tried looking through blargg's notes and source code for ideas?

Well, the band-limited synthesis I keep referring to is the one blargg describes here.

Congrads on the Save State support. I didn't do too many tests on it, but what I did test seems to be working, nice job

Thanks. The fact that I played through several games that I suck at some months ago should be sufficient evidence that it's working pretty well.
I did find a bug in the thumbnail loading just now though. The ifstream used for reading them was missing the binary flag. For some reason I only encountered problems caused by this in the windows build.

[Nach]

The ifstream used for reading them was missing the binary flag. For some reason I only encountered problems caused by this in the windows build.

The vast majority of UNIX systems today make no difference if there's a binary flag or not, it's all binary. So yes, it would only effect Windows, or older OSs really.

[sinamas]

For GCC 4.3:

Code: Select all

Index: libgambatte/src/file/file_zip.cpp
===================================================================
--- libgambatte/src/file/file_zip.cpp   (revision 154)
+++ libgambatte/src/file/file_zip.cpp   (working copy)
@@ -19,6 +19,8 @@

 #include "file.h"

+#include <cstring>
+
 namespace zlib {
 #include "unzip/unzip.h"
 }

When compiling now, I'm noticing hundreds of warnings about ambiguities in bit manipulation.

For some reason with latest SVN, the colors in game are completely wrong.

I'm not using any special palette. Turning on HQ2x makes the whole screen pink.

You mean to say you don't appreciate the new auto-coloring of DMG games?
Thanks. I'll have a look at it as soon as I'm back on a decent *nix setup. I'm guessing it's either related to GCC 4.3 strictness or 64-bit specific.

The only really valid warnings were these two:
src/colorconversion.cpp:43: warning: integer overflow in expression
src/colorconversion.cpp:44: warning: integer overflow in expression

which could probably cause a pink screen on arhitectures where sizeof(long) != sizeof(int) and int isn't 16-bit (besides being strictly undefined), if you were using a YUV-based color format that is. If you were using XV on such an architecture this was probably the problem. Otherwise I haven't been able to reproduce it.

As for the other warnings, I find that adding parentheses around expressions with (to me) obvious precedence tends to clutter up the code. Is it really too much to expect that programmers can be arsed to learn relatively basic operator precedence?

[creaothceann]

As for the other warnings, I find that adding parentheses around expressions with (to me) obvious precedence tends to clutter up the code. Is it really too much to expect that programmers can be arsed to learn relatively basic operator precedence?

Sounds (to me) similar in spirit to "Real men don't need comments. It's all there in the code anyway, so why bother?"

[sinamas]

As for the other warnings, I find that adding parentheses around expressions with (to me) obvious precedence tends to clutter up the code. Is it really too much to expect that programmers can be arsed to learn relatively basic operator precedence?

Sounds (to me) similar in spirit to "Real men don't need comments. It's all there in the code anyway, so why bother?"

IMO comments are useful for explaining stuff that can't be easily encoded in function declarations, variable names or similar, or stuff that looks wrong but is right. I know I'm pretty lazy on the comments though, and I could be better at doing stuff like moving pieces of code into their own appropriately named functions.

Operator precedence is easily learned as you use the operators. There is quite a limited amount of operators. Some operators may be seldomly used in certain kinds of code, but are used a lot for other kinds of code. It seems annoying to me to demand parentheses in short expressions in code heavy of such operators (kind of like having to parenthesize multiplies in more conventional pieces of code). I think it's reasonable to expect that the persons editing that kind of code would familiarize themselves with those operators. Granted, for long expressions doing a bit of grouping can aid readability (and I could probably be better at that), but I think whitespace serves that purpose better.

Now, I realize that a lot of these things depend on personal preference, so if the general consensus among programmers is that bitwise operators should always be parenthesized I may be willing to cave (at least it means I won't have to use -Wno-parentheses to avoid drowning in irrelevant warnings).

[funkyass]

compilers don't warn about human readability issues with the source code its processing, they warn because its not sure if its processing the code correctly, so if something screws up later it at least warned you about it before hand.

-Wparentheses primarily deals with { and }, not ( and ) if I read the GCC docs correctly.