VisualBoyAdvance-M

OK, one more thing: when you were fixing fex_mini.cpp, you broke it.

 

res!=1 is the problem - res is initialized as 0, if fread is not done (that is,

if it's not a gzip file), res stays at 0, so error is incorrectly triggered.

I'm not sure whether it's a problem with nasm (2.05.01) or cmake (2.6.2), but recent svn does not build with USE_ASM_SCALERS. The error is: src/filters/hq/asm/hq3x_16.asm:21: fatal: unable to open include file `macros.mac' The actual command is: /usr/bin/nasm -f elf -Isrc/hq/asm/ -O1 -DELF -w-orphan...

Well, I'm not sure.

Recently, I haven't been using vbam much.

Today I tested it simply to see if update to

xorg-server 1.5.0 fixed the performance issues

with open radeon driver/DRI/Composite combo

(it didn't, btw., maybe it gets better when dri2

gets fully implemented).

Long time no see.   This time something rather trivial. Current svn is unbuildable with gcc 4.3.   Following files need #include : src/gtk/configfile.cpp src/gtk/screenarea.cpp src/gtk/screenarea-cairo.cpp src/gtk/screenarea-xvideo.cpp src/gtk/screenarea-opengl.cpp   BTW, before when gvbam was ru...

That version doesn't compile.

In fact it looks like what you commited is a part of some changes,

that are not yet in the tree.

1. there doesn't seem to be any m_poFilter2x (reverted that change)

1. ‘pAttr’ was not declared in this scope (by guessing, I decided it should have XvAttribute* type)

A new day, a new bug. This is actually an old one, but I was hoping it was a driver bug, but it doesn't seem that way.   xf86-video-ati has introduced textured video adaptor for Xv. However, that adaptor has no port attributes, so Atom oAtom = XInternAtom(m_pDisplay, "XV_AUTOPAINT_COLORKEY&quo...

Just to add my 2c: blindly following HIG is simply dumb.

I tend to violently disagree with Gnome HIG policy:

they tend to "simplify" interface up to and beyond the point

were any sane configuring is simply no longer possible.

It does work better, but that asm problem is still there. The incorrect CMakeFiles/CMakeASMCompiler.cmake: SET(CMAKE_ASM_COMPILER "/usr/bin/nasm") SET(CMAKE_ASM_COMPILER_ARG1 "") SET(CMAKE_AR "/usr/bin/ar") SET(CMAKE_RANLIB "/usr/bin/ranlib") SET(CMAKE_LINKER ...

The catch is that I meant:

I have to run cmake, delete CMakeFiles/CMakeASMCompiler.cmake first time it's generated and rerun cmake to get it to work.

And it should either set that policy to old or require cmake 2.6.0.

First of all, it seems that cmake 2.6.0 is required to do it, cause for some reason I was unable to use them, till I upgraded. Now, a question: why does compiling of c version take a few orders of magnitude more time than the asm version ? And a minor annoyance: unless I add '-w-orphan-labels' in CM...