About multi monitor: Personally, since most games don't fullscreen well with dual screen in linux, I just maximize the window on the monitor I want and then undecorate the window. I also set my window manager up to do this automatically (the joys of using openbox)
When launching jasper not from current directory it segfaults:
Segmentation fault (core dumped)
Program terminated with signal 11, Segmentation fault.
#0  0x080577ec in load_all_pods ()
#0  0x080577ec in load_all_pods ()
#1  0x080541dc in jasper_init ()
#2  0x08054276 in main ()
Aptosid 64bit (= Debian Sid) - starts and works perfectly.
$ uname -a
Linux jager 2.6.37-2.slh.3-aptosid-amd64 #1 SMP PREEMPT Sat Feb 26 04:03:42 UTC 2011 x86_64 GNU/Linux
$ glxinfo | grep render
direct rendering: Yes
OpenGL renderer string: Gallium 0.4 on ATI RS482
GL_MESA_window_pos, GL_NV_blend_square, GL_NV_conditional_render,
first of all thanks for a great game and for supporting Linux. In case any one is interested I have created a .deb package that installs Jasper's Journey into /opt/JaspersJourneys and creates a nice little menu item in the games menu.
If this is not to your liking (Lexaloffle) tell me and I will remove it asap.
And btw, most Linux distributions does not need the bundled libraries. For example Ubuntu already have the SDL and SDL_mixer libraries installed with the correct version (and probably has since at least 8.04).
I just tested this game on my netbook (Samsung NC10) running Ubuntu Lucid 10.04, Kernel 2.6.34-020634-generic, fluxbox windowmanager. Runs very well and smooth!
I like this game, how or when can I buy it to support further development/porting of your games? Should I just buy windows/mac version and use the version from this thread or should I wait for a "buy linux version" button on your page?
Ubuntu 10.10, Logitech Dual Action Gamepad (I've used this with no problem playing other games)
Pressing the gamepad's hat at any point closes the game unexpectedly.
The control stick is sensitive to the point where it is ignored when pressed to the side all of the way without first being held part of the way.
Also, noticeable tearing, but I think that point has already been covered.
Other than that, it looks like a great game, I'll play for a little while longer :-)
Just a comment on the dual screen thing: that's not for you (the game developer) to deal with.  That's an end-user settings thing that most people just don't know how to do.  Two possible ways are listed below:
1) Dual Head (also known as Zaphod, after Hitchiker's Guide) mode.  What this does is run two separate X11 instances.
How: Bleh, this is posted all over the place.  I use nvidia-settings, so I really can't talk.  Just search for "xorg zaphod" or something along those lines.
Advantages: full screen works properly on only one screen out of the box, each monitor properly restricts the mouse and windows to only the displayable area on the monitor, works independent of video cards.
Disadvantages: since these are two separate X instances, you cannot drag windows between monitors.  You can move your mouse from one to the other and back, but windows need to stay behind.
2) MetaModes.  This allows you to define multiple modes, so that when a program fullscreens, it can use a non-twinview mode.
How: Put the following under your "Device" section, replacing |left_x| with your left screen's x resolution, |left_y| with your left screen's y resolution, etc.:
Option "MetaModes" "|left_x|x|left_y| +0+0,|right_x|x|right_y| +|left_x|;|left_x|x|left_y|;" # You can add more modes WIDTHxHEIGHT and separate them with semicolons after that last semicolon
Advantages: You can drag windows between screens.
Disadvantages: It requires a little extra setup and the syntax of the metamodes option can be confusing and the actual X display will be a true rectangle, so you may have some weird extra space outside of the actual display on the smaller screen of the two (if one is smaller than the other).
Also, the MetaModes option might (I'm not sure about this, as I have yet to try it) actually change the resolution of the X server while the fullscreen program is active, thus disabling your second screen.  I'll try that in a few minutes, actually.
About the screen resizing issue:
it's quite easy to do this in SDL only, without depending on opengl (though of course not saying an opengl option wouldn't be appreciated)
In fact I compiled my own SDL library this morning just so I could resize Jasper's window (it was too itty bitty D:)
Let's say you have the SDL_Surface*'s for the game screen (at 640x480) and the output screen (set by SDL_SetVideoMode and can hook into the resize event or whatever.
Then you can call  int SDL_SoftStretch(SDL_Surface *src, SDL_Rect *srcrect, SDL_Surface *dst, SDL_Rect *dstrect) which isn't super well documented, but it's in the current stable source, to blit and scale from the game screen to the output screen. (make sure to compile with USE_ASM_STRETCH defined if you want the hand crafted assembly version, use at your own risk xP)
Runs like a charm for me (on my fast computer ;D), even with an extra uneccessary blit of the entire 640x480 screen every frame for me, because I was limited to messing with the SDL side of things and couldn't change the source code
I can't make official releases extremely soon (for good reasons that I can't discuss yet!) but at this point I'd be more than happy to take any registered users on as beta testers. That goes for Zen, Chocolate, Jasper & Neko. Just send me an email (hey [at] lexaloffle [dot] com) and I'll set your account up with a Linux link (the license is for all 3 platforms btw).
Regarding tiny window sizes (640x480 is too small at high resolutions), I added a 1.5x scaling mode rather than allowing arbitrary scaling. It's not so CPU-intensive and less blurry.
LOR: thanks for the translation/summary, that's awesome!
KameZero, valczir: yep, I think multi-monitor support should be a window manager thing. I'll include your suggestions in the help docs if you don't mind
Henrick: cheers, I hadn't figured out how to make .deb packages yet
j-maks: The SAVE is upside down because the disk it's written on is upside down :p
zhuravlik: Wow, nice catch. It's kind of a nice old-school bug, I'm not sure if I should fix it.
KameZero: For sure, Desura looks great. In the past I've had trouble getting distributors interested in my games, but hopefully I can also smuggle them onto other services along with Voxatron.
Creating DEB:s or RPM:s is not that difficult actually even though finding out how to do it can be quite an interesting task. For DEB:s there are two choices, either to use the debbuild script (if anyone is interested in how that is done, don't hesitate to ask me), or to simply tar a few files.
For the Jaspers Journeys package I choose to go with the second route since I didn't have access to the source code (debbuilder usually wants to build the software).
1. Create a project folder. Say "jasper"
2. In this folder we create subfolders mimicking the folders where we will install everything. Since external applications (i.e software that is not installed by the distribution) should be installed to /opt/, I choose as most other games do to install into /opt/JaspersJourneys. We also want to add a menu item so we have to install a file into /usr/share/applications/
So in the "jasper" folder I created the following folders:
3. I placed all the jasper files into "jasper/opt/JaspersJourneys", and I created a "jasper/usr/share/applications/jaspersjourneys.desktop" file with the following data:
4. I created the control file for debian as "jasper/control" with the following data:
Description: Jasper's Journeys (demo)
A fantasy retro platform game from Lexaloffle. Demo version.
The BBS code hides a space before "A fantasy" on the last line is vital (it indicates that it's the long description). For a proper .deb one should also add a "Maintainer: e-mail address" line.
5. Create a "jasper/debian-binary" file with the following data:
6. Then I wrote a simple script that creates the .deb file. These script lines could easily be added to the makefile so one can type "make deb" to make a .deb. We also must make sure that the makefile moves all the files to the jasper/opt/JaspersJourneys folder :). The small script contains these few lines:
tar --owner=root --group=root -czf data.tar.gz opt/JaspersJourneys/ usr/share/applications/
tar --owner=root --group=root -czf control.tar.gz control
ar -rcsD jaspers-journeys.deb debian-binary control.tar.gz data.tar.gz
And that is all that is needed, one simply have to run that script when rebuilding the deb, and also update "Version:" in the control file of course.
If interested in how to build a rpm don't hesitate to ask, it's quite simple as well.
"Regarding tiny window sizes (640x480 is too small at high resolutions), I added a 1.5x scaling mode rather than allowing arbitrary scaling. It's not so CPU-intensive and less blurry."
Once again, you'd be way better with an OpenGL backend. SDL provides souch a backend. You could then use arbitraty scaling with no CPU wasting. And you could provide smooth scoll withou tearing, too.
OpenGL is a cross-platform standard and SDL makes it relatively easy to use OpenGL as a backend for 2D SDL apps.
Well, I'm a bit late for the party, but I just gave the game a run, and it worked perfecly for me--though I don't remember there being a story before.  )  I'm currently running Ubuntu 11.04 (64-bit), and I've got small cache of fireworks set aside for when Voxeltron is  released.
valczir: zaphod mode is severely deprecated and spends very long periods of time broken. I suspect it won't remain in the X server for much longer. TwinView is nvidia-specific and will never be supported for anyone using any other cards.
The X.org-supported methods of doing multiple screens are Xinerama (itself somewhat deprecated, but still widely used) and the X RandR extension (which nvidia *still* doesn't support, something like five years after its inception). The latter is far preferable from a flexibility perspective, as it allows any number of screens of any resolution in any position, and allows this to change dynamically: pretty much all free X video drivers support it, while not a single one supports TwinView nor ever will.
Unfortunately SDL 1.2's support for RandR is suboptimal to say the least and cannot be fixed without an API change (coming in SDL 1.3 any decade now). It is relatively easy to make it work 'well enough', sizing and positioning appropriately for a single screen. Virtually every SDL app does that right: in fact, voxatron is the first I've seen that doesn't, so it should be easy to see how to fix it with such a wealth of examples :) )