SDL Quake port using Notaz's SDL - couple of questions before release

[j0e]

Hey guys,

just spent the afternoon compiling the sources for SDL quake on my pandora. Works like a charm - mostly. Just a couple of questions/issues that I'd like to fix before making a release:

1) I'm using Notaz's SDL and when I move the mouse (a USB mouse or one of the nubs in mouse mode) the player spins around wildly as if the mouse sensitivity was 9999 or something. Oddly, this only seems to happen most of the time, occasionally not happening at all. After setting the mouse sensitivity to 0.1 in the console, the player now looks around at a constant speed in 8 directions and very very late after I've moved the mouse. Very very slight movements of the player show that the actual real mouse movement is also still present.

This problem isn't present at all when using the normal SDL.

Is this a documented issue? How would I go about fixing it? If required I can stick up the binaries after I finish eating dinner (I'm eating it right now).

2) If I put a load of environment variables (export SDL_VIDEODRIVER=omapdss) in the script before starting Quake, how would I reset them back to what they were before Quake was run? Will they reset by themselves? I tried doing export SDL_VIDEODRIVER="" after running Quake but after that it won't run unless I do export SDL_VIDEODRIVER=omapdss again, even though doing echo ${SDL_VIDEODRIVER} beforehand returned an empty string.

 

[ptitSeb]

Hey guys,

just spent the afternoon compiling the sources for SDL quake on my pandora. Works like a charm - mostly. Just a couple of questions/issues that I'd like to fix before making a release:

1) I'm using Notaz's SDL and when I move the mouse (a USB mouse or one of the nubs in mouse mode) the player spins around wildly as if the mouse sensitivity was 9999 or something. Oddly, this only seems to happen most of the time, occasionally not happening at all. After setting the mouse sensitivity to 0.1 in the console, the player now looks around at a constant speed in 8 directions and very very late after I've moved the mouse. Very very slight movements of the player show that the actual real mouse movement is also still present.

This problem isn't present at all when using the normal SDL.

Is this a documented issue? How would I go about fixing it? If required I can stick up the binaries after I finish eating dinner (I'm eating it right now).

2) If I put a load of environment variables (export SDL_VIDEODRIVER=omapdss) in the script before starting Quake, how would I reset them back to what they were before Quake was run? Will they reset by themselves? I tried doing export SDL_VIDEODRIVER="" after running Quake but after that it won't run unless I do export SDL_VIDEODRIVER=omapdss again, even though doing echo ${SDL_VIDEODRIVER} beforehand returned an empty string.

1/ I'm afraid it's some side effect of TSLib. Not completely sure and clear on that subject, but I have not found working workaround for that.

2/ No need to. Once your script is over, all it export are reverted back to their initial state (but the command would be "unset SDL_VIDEODRIVER").

 

[j0e]

Hey ptitSeb, cheers for your quick answer.

1) I did try setting SDL_OMAP_TS_FORCE_TSLIB to 1 before running quake but that just disabled the mouse (both movement and buttons) and nubs entirely. Strangely, the USB keyboard was not affected. Looks like I may have to release it with no nub support (but then again this port is more intended to provide a "classic" quake experience as opposed to the other ports of Quake on the repo).

2) Thanks for clearing that up; I will give the unset command a go after I finish eating dinner (I'm nearly done!).

 

[ptitSeb]

1) I did try setting SDL_OMAP_TS_FORCE_TSLIB to 1 before running quake but that just disabled the mouse (both movement and buttons) and nubs entirely. Strangely, the USB keyboard was not affected. Looks like I may have to release it with no nub support.

Yes, with that, you have ONLY TSLib. But with 0, both TSLib & standard input seems to used... I have not found a solution for ZDoom (unless adding a new env. variable and do some coding in SDL, that I hadn't start).

 

[TrashyMG]

1) I did try setting SDL_OMAP_TS_FORCE_TSLIB to 1 before running quake but that just disabled the mouse (both movement and buttons) and nubs entirely. Strangely, the USB keyboard was not affected. Looks like I may have to release it with no nub support.

Would Joystick mode work in this case? just would need to add nub mode switch commands in your startup script.

 

[j0e]

Would Joystick mode work in this case? just would need to add nub mode switch commands in your startup script.

Sadly not, I just gave it a go and Quake doesn't respond to either nub joystick.

@ptitSeb: unset worked like a charm, thanks

 

[notaz]

If somebody could write a small testcase that demonstrates misbehaving mouse, it could be fixed in "my" SDL itself.

 

[ptitSeb]

Would Joystick mode work in this case? just would need to add nub mode switch commands in your startup script.

Sadly not, I just gave it a go and Quake doesn't respond to either nub joystick.


@ptitSeb: unset worked like a charm, thanks

For the joystick, take a look a @my nprQuake beta, sources are inside the PND, and you will find some SDL Code to handle joysticks.

 

[j0e]

Hey guys - looks like the PND is working well with one exception: the config file isn't being saved. Not quite sure what is causing this; could it be something to do with the fact that the PND comes with a default config.cfg and as such a new one isn't being saved in the appdata folder?

If somebody could write a small testcase that demonstrates misbehaving mouse, it could be fixed in "my" SDL itself.

When I upload a copy of my Quake build, that will demonstrate the issue clearly, but after I've released it I'll see if I can knock up a quick test program to see what causes this issue.

For the joystick, take a look a @my nprQuake beta, sources are inside the PND, and you will find some SDL Code to handle joysticks.

Cheers, I'll take a look at it tomorrow morning.

 

[sebt3]

If the config file is in a sub diretory which exist inside the PND then its directory have to be created in the appdata as the overlay system wont do that for you. There is an environment variable set to help you there (add a env command in your start script to find it )

 

[lunixbochs]

A naive solution to things like rewritable config files: store it in a different folder, and copy it to the right place on start if it doesn't already exist there.

This means it gets prepopulated on first launch but the user can still edit it.

My solution for more complicated games like stepmania and aquaria is to extract a tarball to the root based on some condition or another. I also store the applied overlay version in a file so I can update the tarball in the pnd to give the user a new overlay. I guess an even more advanced version would be to not overwrite config/save files using the same system.

 

[notaz]

Actually files inside the .pnd can be modified just fine (it's handled by aufs), there is no need for above workarounds. You just have to set correct unix permissions on files before packing them into the .pnd: the files have to be writable by "others" and owned by root (this is to match how fat partitions are mounted). Latest pnd_make.sh from git ( http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-libraries.git;a=blob_plain;f=testdata/scripts/pnd_make.sh;h=fed33961756956b87bcf7bc612a3136f106dca05 ) already sets correct owner, you just have to set w+o permission on config files that are to be modified later.

 

[lunixbochs]

What about directory creation?

 

[j0e]

I tried making the pnd again, this time using pnd_make.sh, and I'm now able to write a config file and save and load games correctly. Packaging pak0.pak in the pnd and putting pak1.pak in the appdata directory also works as expected. Expect a release shortly, after I've implemented joystick support

 

[j0e]

Hang on, I just read in the nprquake thread that the right nub is mouselook, which would cause the exact same problem since mouse movement is buggy. I believe it might be something to do with the SDL cursor not being correctly repositioned in the centre of the screen as it should be with FPS games, thereby moving the player by the distance the mouse is away from the centre of the screen rather than how much the mouse was actually moved.

Edit; It looks like SDL_WarpMouse isn't doing what it's supposed to. Although it's called every frame, the weird issue still persists. When turning displaying the cursor on, there is indeed a cursor that appears in the middle of the screen but also another, occasionally flickering cursor that moves around as I move the mouse, which appears to be the "true" cursor. SDL_WarpMouse works as expected if not using Notaz's SDL driver.

 

[ptitSeb]

Hang on, I just read in the nprquake thread that the right nub is mouselook, which would cause the exact same problem since mouse movement is buggy. I believe it might be something to do with the SDL cursor not being correctly repositioned in the centre of the screen as it should be with FPS games, thereby moving the player by the distance the mouse is away from the centre of the screen rather than how much the mouse was actually moved.

nprQuake doesn't use Notaz'driver, so the mouse behavour is not affected. But I do have the same behavour you discribed with ZDoom.

 

[Loonie]

The mad rotation is definitely not random, there is method to its madness. If the camera is spinning wildly left and you very slowly keep moving the mouse to the right, the mad camera rotation left will eventually begin to slow until it starts rotating right and building momentum in that direction instead. The same is obviously true vice versa.

 

[j0e]

Yep, that is the very effect I observed - perhaps I didn't explain it very well in my previous post.

Anyway, I thought I had updated this topic a while ago but clearly not - I would have released this by now but I'm experiencing random segmentation faults (of course) at times during gameplay. They always seem to happen at completely random points with no discernible connection between them. I might try debugging the program but I already know full well all I'll get from the stacktrace is "?? () ()" as I always do...