Re: Playable Quetoo (Quake2) port for N800
 

I didn't know the N800 could upscale RGB formats too. Would probably be quite a bit faster, since no conversion would be needed, but is there any simple way it can be done with SDL?

I'm not sure if the 770 is powerful enough to run the game at all, though XSP shouldn't be that hard to implement. Though atleast I far prefer the smooth scaling Xv does, than a simple pixel doubling would.

Re: Playable Quetoo (Quake2) port for N800
 

I don't think that it is exposed through SDL API, but you can try to use omapfb ioctl calls for screen update directly. Also probably Xv could support RGB565 format along with YUV as additional bonus, but it needs to be checked, I don't remember exactly.

If N800 is fast enough to run quake2 in 400x240 mode, XSP will provide some speedup because you will not have to do that RGB->YUV conversion in software.

Pixel doubling is a bit misleading name most likely inherited from epson documentation. Actually it does smooth scaling.

Re: Playable Quetoo (Quake2) port for N800
 

I've built this with pixel doubling and the whole thing works good. XSP pixel doubling is pretty easy and i just did a quick benchmark to give you idea of results to expect :

@400x240 I set a bind in both configs to 'timedemo 1; map demo1.dm2'

Your build ran 9.3 fps
Xsp build ran 12.4 fps

So i would say it would be very worthy to implement xsp but that may limit your ability to implement other resolutions (maybe not needed for speed?) I guess you could scale within 400x240 window.

What i did was edit vid_sdl.c where it sets video mode i check if width is 400 and if so i drop in xsp code (mostly copy and pasted ) from here :
http://maemo.org/community/wiki/gamedevelopment/

make sure to add linker flags -lXsp so that libraries are pulled in.

Your launcher is great! Very creative use of launch script.

Although i have version 1 installers i wont bother posting links to them unless you want a hands on side by side test.

Oh, yea.. i was also able to join in a network game by adding +connect 192.168.1.100 to connect to my desktop (official quake2) game so it seems multiplayer is supported and works although probably only makes sense to play other tablet users.

How cool would that be if you could implement some kind of multiplayer game join/setup to your launcher ! Boy requesting features is fun!

I was also able to run ctf game but i had issues with game dir ... i had to put ctf pak file (11megs) on internal memory with ctf game library. Still alot of possibilities... maybe an ITT ctf server.

Re: Playable Quetoo (Quake2) port for N800
 

I also made a quick version, which uses XSP to do the scaling rather than converting to an overlay and while the game reports a higher fps, the actual gameplay feels more jerky. I think'll keep the overlay scaling for now, atleast until I can figure out, what I'm doing wrong with XSP.

I already started adding multiplayer join to the launcher, so that'll be in the next version.

I uploaded binaries for a XSP version to http://www2.lut.fi/~thietan1/quetoo/quetoo-xsp.tar.bz2 and sources to http://www2.lut.fi/~thietan1/quetoo/...sp-src.tar.bz2.

Re: Playable Quetoo (Quake2) port for N800
 

Apparently that's the problem with tearsync. It is enabled for YUV screen updates in xserver, but is turned off for normal RGB updates (to avoid a tearing line at the bottom part of screen because of slow screen update speed). So overall N800 hardware is capable of doing arbitrary upscaling for RGB with tearsync, these features are also supported in omapfb kernel driver (except for 24-bit and 32-bit video modes), but all this good stuff is not available for use from xserver and SDL. Maybe it makes sense submitting a feature request at maemo bugzilla to ask for some way of using these features (probably the most easy way would be to allow setting arbitrary screen resolutions implemented via the use of hardware scaling). I would not hold breath though, as Nokia developers were very reluctant to implement even XSP support (initial N800 firmware did not have a working pixel doubling). The best chance to get this stuff working would be to hack xserver (sources are available fortunately) and add all the needed features to it, submit a patch to maemo bugzilla and hope that it might get into official firmware release eventually :)

Re: Playable Quetoo (Quake2) port for N800
 

Yep... sounds familiar. I implemented a quick absolute positioning mouse at first but it seemed as though the actual touchscreen (or touchscreen movement) bogged it down.

The default accelerating mouse is annoying but it didnt seem to bog down input as much so i left it in... until maybe a last ditch effort to try workarounds. As annoying as it is it can pan around sooo smooth... i think because your not constantly -moving the stylus- just setting a location to track to... while the absolute positioning resulted in a flurry of SDL movement callbacks.

Perhaps you are at that point. Maybe you can trap the event queue for mouse movements and respond to only every third movement or something... see if that helps.

see if dpad movement (or timedemos) feels smoother (no stylus input) to see if this might be it.

Re: Playable Quetoo (Quake2) port for N800
 

I did some testing, and while it does appear the game is not as jerky when not using the stylus, it's quite hard to tell. Why would the stylus movement not slow down the overlay scaled version just as much as it does the xsp doubled one?

But I think I'll make the game use the xsp doubling at 400x240 and the overlay with any other for now, since it doesn't really run playably at 400x240 with the overlay scaling anyway (though the RGB->YUY2 conversion can probably still be optimized considerably).

I might even look into modifying the xserver to allow scaling to any resolution, though the game works well enough at something like 320x192 with the scaled overlay, so I'll probably be doing some other work first.

Re: Playable Quetoo (Quake2) port for N800
 

Your latest version running pixel doubled has very smooth look now. Well done!

I had to do some other tweaks and im not sure how many helped but :

The most important tweak was to go into maemo control panel and under sounds, Disable the Key sounds.

You notice how buttons make a noise when pressed as 'feedback'... well in the game when you keep a key held down and move the stylus its like re-registering the key event, causing a barrage of sound interruptions... as if only one input (button or touchscreen) allowed at a time. By disabling the key sound its probably just avoiding cpu burden/interrupting to play that sound... which may be helping responsiveness but if for anything it just helps me keep my sanity. The hardware limitation (hack?) is probably still there... it just doesnt burden machine to 'notify' you falsely about it being a 'new' button press 10 times a second... when you actually never released it.

I also added these lines to autoexec.cfg :
precache 1
+mlook
bind mouse1 ""

precache might help (assuming it works as advertised)
i doubt the mouse commands change anything different from how you have it... but thats a good default i use.

So this is pretty much great for me although i might tweak configs or post my configs. I wonder if programs can disable those system sounds automatically (restoring old button sound state when done)... i dont really need button sounds (just wondering how one might do it).. touchscreen sounds are all i really need.


-default keybind suggestion-
Since users cant save might be nice change f4 bind to something like :
bind f4 "give shotgun; help"

At least then they have minimum weapon they can call up using menu key, which can get them out of more early situations until they can find better weapons

Not sure how you are packaging but you could convert the icon in the src directory to png and put into /usr/share/pixmaps and reference from .desktop file to add q2 icon to menu. The latest version of pypackager will let you also pick that icon to use in the uninstall menu (nice to see even if your uninstalling a different app)... not sure how that would be done without pypackager.


Great work... ill be watching out for impovements.

Re: Playable Quetoo (Quake2) port for N800
 

I've uploaded an third release again to http://www2.lut.fi/~thietan1/quetoo/. New is the XSP doubling for 400x240 and the launcher has received some new options, including ability to connect to a multiplayer game.

I've also put a deathmatch server running at zerion.selfip.net, if people would like to try out the multiplayer.

Hadn't even thought about the default feedback sounds the device has. I just hate those so I've always disabled them right after flashing. I don't know if they could be disabled for the duration of the game, but I'll try looking into that.

The page http://console.planetquake.gamespy.c...s/quake_2.html tells me
So I don't think that precache option should do anything in autoexec.cfg. Mouselook should be on by default and I already have that 'unbindall' command in the autoexec.cfg, which clears the mouse1 binding.

I'd rather have the game save the game when exited and then continue from that point when next launched, but I'm not sure if saving works with quetoo, I'll have to try asking the upstream author about that. But if it doesn't I'll have to add something like that.

The package already installs some icons into '/usr/share/icons/hicolor/26x26/hildon' and such, and they are referenced in the .desktop file. Don't really know why they don't seem to display. The deb control file also has the XBS-Maemo-Icon-26, with the icon in base64 and it does display in the app manager for me.

Re: Playable Quetoo (Quake2) port for N800
 

server working great. we should schedule a n800 deathmatch.