I would suspect an off-by-one/rounding/implicit-conversion problem in the code calculating the tex-coords. Float tex-coords are very common, and at least I personally have never run into problems with float precission using them in OpenGL...

[...] The direct download is also needed if you provided Mac/Linux versions, given the Desura client doesn't even exist for those platforms.

That is not true, the Desura client definitley exists for Linux at least. The download page only offers you the version for your currently running OS by default though.
 

What version of GCC and binutils are you using? I was able to compile that code without problems with either GCC 3.4, 4.4 and 4.6 and binutils 2.20.1.

The order in which you specify objects (or source in your case) and libraries may be problematic - try putting all the "-l..." flags at the end of the command line.

Also try to separate compilation and linking, and see if that makes a difference:

Code:

gcc -Wall -pedantic -c prime1.c
gcc -o prime1 prime1.o -lm

This might be of interest: http://ccrma.stanford.edu/software/stk/index.html

People who did not own a gamecube are in for a treat, but I already own all three MPs (as well as the original Pikmins...) and I actually find these re-releases annoying - especially considering that the Wii has perfect backward compatibility...

Release some *new* games for Wii for a change, Nintendo!

http://jnrdev.72dpiarmy.com/

The SNES uses a lossy compression format for it's samples. One way of emulating the SNES sound would be to take regular 16 bit instrument samples, then "dirtify" them by converting them to the SNES format, and then convert them back to 16 bit samples to use in a tracker. I think command line tools exist for this (WAV to BRR conversion and back). Also lowering the sample rate might help, I think the SNES uses 30kHz.

I also remember that loops in samples on the SNES have to be aligned to blocks of 16 samples, so experimenting with "unclean" loops could also help.

Other than that the unique sound and capabilities of the SNES sound chip will make it difficult to reproduce that sound... especially regarding fx.

The perfect way to do it would be to use an SPC emulation library and provide your tunes and effects as an SPC program...

And nothing I use to free it seems to work without giving some indecipherable errors about heaps and death and destruction being rained down on the unsuspecting bits of my RAM.

I've tried these so far:

Code:

delete [] *tiles;
delete [] tiles;

for (int i = 0; i <= x; i++) {
     free(this->tiles[i]);
}
free(this->tiles);

And various combinations of the two.

If anyone could give me some pointers (no pun intended) to help me in the right direction that'd be awesome. If you need more source code I'd be happy to provide.

Don't mix malloc/free and new/delete. Without the delete statements that code actually looks correct t me. I think you need to look at the context this code runs in (how/when/in what order is it called, how is 'x' set...) to find the error... finding out what those "indecipherable errors" mean would also be a good start

The problem seems to be that _WIN32 is used to detect 32 vs. 64 bit compilation, which obviously does not work in non-Windows systems. According to this, _WIN32 is also set when compiling in 64 bit mode so this does not to what you might expect even on Windows...

I think this could be solved by changing code like this:

Code:

#ifdef _WIN32
        while (((int)data)!=(((int)data)&(0xfffffffc)))
#else
        while (((long long)data)!=(((long long)data)&(0xfffffffffffffffc)))
#endif

...to something like this:

Code:

#if not defined( _WIN64 ) && not defined( __64BIT__ ) // Proper VisualC++ 64 bit detection, G++ 64 bit detection...
        while (((int)data)!=(((int)data)&(0xfffffffc)))
#else
        while (((long long)data)!=(((long long)data)&(0xfffffffffffffffc)))
#endif

Thanks all...

minasss, if I compile using Mesa and then I distribute the game, will it run on other people's machines using Mesa or will it use the local hardware acceleration?

If you just link dynamically to libGL, it should use whatever is installed on the target system - either Mesa (which *has* hardware accelerated backends for some cards), or the proprietary implementation from Nvidia or ATI.

The VM thing is actually a really good idea... unfortunately my options are sharply restricted on that front because my mac is PPC and can't run VMWare etc. Thinking about it though maybe I can get Linux to run under qemu... I will see how workable that turns out to be.

Qemu is trivial to set up if you don't need tun/tap networking. I usually just set up port redirection for SSH or other ports i need.

Code:

qemu -redir tcp:2222::22 disk.img

I use a setup like that at work to run a script locally that logs into the Qemu system, runs a script on there that checks out some stuff from SVN, compiles it and then downloads the build to my local machine with scp.

It would probably not be too much work to build my game for Mac and Linux since I'm using SDL/OpenGL.  But I don't know the first thing about developing for these platforms and I don't happen to have instances of them lying around to try it out on either.  Is it possible to compile a game for Mac/Linux on Windows?  Then I could send it to friends with these machines and make sure it works without them having to go through the hassle of trying to build it themselves.

Building a cross compiler for Mac was not easily possible last time I checked because you need parts of the Apple SDK to work on your build system (I tried Linux to Mac, and gave up after many hours). You could probably build a Windows to Linux cross compiler using Cygwin.

The easiest way to create a Linux build system though would be to get VirtualBox or any other virtualization software and just install a Linux distribution on it.

Badgers?

More oldies:

Space Hulk comes to mind.
And one of my all time faves (not turn based though): System Shock.