Re: Xsp pixel-doubling solutions for Nokia 770?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Eero Tamminen wrote: > Hi, > > ext Frantisek Dufka wrote: >>> And if the game doesn't disable the double pixeling properly (e.g. if it >>> crashes or freezes), user needs to reboot the device. Not very nice >>> either... >>> >> So what happened to idea mentioned here year ago to modify Xsp (or >> whatever) API so that pixel doubling is flag of each display update >> separately? I.e. every update would be not pixel doubled unless told so >> by flag with each update. This is how it works on kernel framebuffer >> level anyway. I would double this. Even through we could switch to lower resolution, it would still be beneficial to have option to have just some parts of the screen pixeldoubled. One of these cases is a game which would draw everything (except static gui parts) pixeldoubled when the scenery moves and then draws everything in hi-res when the scenery freezes (and only small parts of the scenery moves). >> >> It is bad to turn in on and off because any other display update >> (infoprint) can mess it up. If we had blitting API in Xsp with pixel >> doubling flag settable per update this problem would go away. >> > > Also, it would be good to support the standard resolutions like 320x200 > (with black borders) so that more programs would work unmodified. Many > games/emulators want a specific resolution. > For example SDL gets smallest res which is equally as big or bigger than requested and gives a window of requested size having black borders around it (I am talking obviously about fullscreen behavior here). Of course, there is some games which doesn't use SDL but plain X, but even in this case when you request fullscreen window, you will get one and if you draw into 0,0 you end up having your "small window" in topleft corner. Of course there is many possibilities for clipping problems and other things breaking up, but the point is, if you want to write a resolution specific game, you probably want to use SDL. > >> Pixel doubled resolutions would be nice and would be improvement over >> current situation indeed. What we will miss with this solution is having >> some parts of screen pixel doubled and some not > > Games can already do this on 770 by setting pixel doubling on after > blitting the more detailed graphics. But as you said RandR doesn't > support that. Besides, the infoprints would still look funny. Not > as funny as with pixel doubling, but they would be too large and > as window manager positions them right aligned, they would be clipped > from the left instead of right like with Xsp. :-) > > What is really needed is a flag that is window specific. > In theory it could be possible that one window (or one client) thinks that the resolution is 400*240 but it really isn't for other clients. In fullscreen world, this is rather simple and you would get for example hi-res infoprints on top of pixeldoubled game window. But again, I'm not the most specialized on these things, so it might be that doing this would be _really_ dirty. > >> like nice control area with nice static graphics and main pixel >> doubled game area. > > I don't think it would be a great loss if the whole window would be > pixel doubled. The screen is 226 DPI. Pixel doubled it would still > 113 DPI, i.e. more accurate than most (CRT) monitors. A bonus would > be that game would use less memory for its graphics (as they are > smaller) and you don't need to modify the game to support two screen > resolutions. IMO this is a loss. There is many things which you could do with the blit-specific doubling. If it is possible to have both, why to drop another (unless we are speaking about something which might potentially break things)? - -- Kuisma -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGNb8KHIcMorDK+qsRAizOAJ9i6oWLrw6hjSzpRi0/nuCh3yaD9gCfZXoH 2f8CS2naOgKGmXPiD9sgLhY= =PIKI -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] joystick
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, this might sound retarded/joke but this is not a joke. I am wondering is anyone using 770 with a USB joystick? It could be possible in USB host mode to actually use one if it takes very little power. The reason I am asking this for is that especially if somebody has actual use case with SDL and joystick. I am planning to remove joystick support from SDL in maemo for now (the version will hit the sardine) and possibly re-include it later. - -- Kuisma -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFbFfvHIcMorDK+qsRAhuSAJ9MsALnoaz9/+/nIF+OXrPVFajgpwCfesc1 sgXdnuitNBYoGCchtYckAXU= =JoA4 -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] XML Question
Hi, Dionisis Petromanolakis wrote: > hi all, > > i need a tool, written in c, to create an xml document automatically with c > commands. Does anyone know if there is one available in maemo or i should > create my own? libxml is shipped with the product, you probably want to use it unless you want to output very simple xml. The libxml docs: http://xmlsoft.org/html/libxml-lib.html -- Kuisma ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Building a binary package?
> I am new to the Nokia 770 development (as well as debian packages) and have > recently finished setting up the development environment (Maemo 2.0). So > far > I have got everything up and running and I have been able to build a simple > Hello World application from scratchbox. I ran it in the emulator (Xephyr) > and now I am trying to run it in the Nokia 770. I have been trying to build > a binary package that includes the helloworld executable, but so far I have > not been successful. Is there any simple way to quickly build a binary > package from my helloworld executable? I have been able to build the > maemopad example package, but since my project has only 1 file, I was > wondering if there is a simpler way to create my package (avoiding all the > makefiles). BTW, using dpkg-deb I managed to build a package but the 770 > complained it was not installable. As you are obviously wanting only a binary package, I am forgetting about debian policies (dirty me). My guess about what happened here is that when you built it with dpkg-deb, it archived your file into the package but was lacking of (at least proper) control file. More info about deb (binary) packages: http://www-128.ibm.com/developerworks/linux/library/l-debpkg.html (Wasn't actually best possible article, but couldn't find better for now.) Anyway, to understand debian bin packages better, I would recommend reverse engineering. So first take any IT2006 bin deb package and take a closer look at it. .deb packages are actually ar packages, so you can extract one using 'ar x'. You should manage from this point, and after a while you should be able to build your own bin package. Now if you actually would make into your source package directory called 'debian' and put there proper 'rules' file there (please correct me if i am missing something (something that is NOT invoked by debian/rules)), you should have working source package. However at this point it might be easier to stick with debhelper and debian policy, so eventually this could be useful reading: http://www.debian.org/doc/devel-manuals ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] flasher2 for linux PPC
Hi, [EMAIL PROTECTED]:/home/prometoys/projekte/gnome/maemo# ./flasher.linux_ppc -F BETA.SU-18_2006SE_0.2006.22-21_PR_F5_MR0_ARM.bin maybe you should try to add -f to the end? -- Kuisma ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] SDL vertical blank (vbl) sync.
My "flashingTest" reports that: It got a hardware surface (I should be writing directly to "video memory" accordingly to the SDL docs) And the surface is double buffered. Don't trust SDL, SDL is a liar. In X backend the SDL trusts what X says so "HW surface" could mean actually "server sided pixmap". The size of the surface is 800x480 16 bit (R5G6B5) So there should be at least 1536000 bytes of video memory The video hardware isn't like in traditional desktop PCs, this in not quite right. The display hardware is actually a blackbox which contains it's own memory and outer memory space is fully unaware about this (AFAIK). I suppose the kernel display driver is open-source? AFAIK it is, so you could dig up the sources... -- Kuisma ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] SDL vertical blank (vbl) sync.
Visti Andresen wrote: Hi I was wondering if anyone knows how to sync. the SDL_Flip to the vertical blanking of the display. While it is nice to get 47+ FPS while memset'ing the display, I would rather be synced to the display and avoid the tearing at the cost of FPS. This is actually generic issue, not just SDL one. When you call SDL_Flip() (or SDL_UpdateRects() etc) it "draws" local data to the display HW, and this goes through X. Having synchronization in the display driver would solve this. Anyway I am not the person to say more about this as I am not enough aware of display HW internals to tell how hard implementing this would be and whether it would even be possible. -- Kuisma ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Game implementation on Hildon or SDL? And what about my project
Hi!
ext Daniel Monteiro kirjoitti:
Hi folks
its been a long since I last posted this mailing list
(but Ive been reading it on since then). Im developing
a 3D game engine having mobile devices in mind (and
the 770 is the perfect testbed).
My engine has a system layer called "System
Abstraction Layer" ,responsible for abstracting both
the hadrware and the software ("everything that can be
made in hardware can be made in software", or
something like that - Andrew Tanenbaum).
That is true that you actually can do everything in software but it
costs more in software. It costs in performance. Especially on 770 the
3D engine might be little bit problematic but at least you should always
try to take everything out of the performance.
But now , I cant decide wich way to go: use on the 770
the SAL (System Abstraction Layer) that Im using on
all the other systems (wich is made with SDL) or code
a new SAL for taking advantage of "Maemo" (by maemo, I
mean Hildon, OSSO , etc).
SDL would have a faster hardware access. On the other
hand , Maemo wold be better integrated with the
system, would not need the "GameLauncher", etc.
You actually don't need the gamelauncher for anything unless you
especially want to have it (for UI reasons). The fact is that if you
want to do game programming on the devices, you probably want to
remember some generic rule said somewhere: "when you're doing a game,
you don't need to obey all the rules", meaning that it might be a good
idea to try to hildonize the UI. But again, the choise is yours, do as
ever you like to do! I would still prefer SDL as it let's you use the
resources somewhat more efficiently (trust me, the 770 is not a powerful
machine and you need all the resources you can get).
just to clarify:Coding a new SAL will not be such a
hard work . I will other SAL´s for other plataforms
too.
My project consists of gaming plataform (free - GPL
,but it is only the reference implementation. a closed
source implementation is possible to anyone) that
abstract the current machine and create a "virtual
videogame". it ditacts that the host plataform must
have some features (nothing to hard) and reads the
game from XML files. The idea is to have almost all
game genres easily described in XML+LUA.
The 3D rendering implementation is custum made for
the project, so debugging and testing is always
welcome.
everyone is invited:
http://edd.gamemod.net/forum
all the posts still in portuguese, but english posts
will be replied in english... (translating docs to
english in progress)
sorry if I was somewhat chaotic in my mail. hope
everybody understand it.
thanks
Daniel "NeoStrider" Monteiro
PS: My other Maemo project, KidSketch is not dead. Im
waiting for the goods (rendering libs, etc) from this
GamePlataform project to use it on the KidSketch.
-- Kuisma
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] display problem
Jussi Kukkonen wrote: Ziqi He wrote: Hi all: I want to use Maemo as the GUI of my system, and the resolution of Maemo is 800*480. The trouble I encountered is that my LCD is 320*240. How can I dl with the problem? Can I display Maemo normally on my LCD? Hello, You have asked the same question three or four times. If someone had the answer you're looking for, he/she would probably have told you by now. To sum up the previous answers: * it's not possible just by a compile switch or something, currently Maemo is 800*480, period. * Making Maemo actually scalable is a big undertaking. Just making a new 320*240 version might be an easier job: Theme changes and modifications to statusbar are still definitely needed. My comments: Even if the OS itself worked, 95% of the apps won't -- Your resolution is only 20% of the maemo "standard". HTH, It is true that this has been discussed before, but never seen anybody suggesting this: One way to get maemo running on a display of 320*240 would be hacking little bit X server (or the display driver) to pretend to be 800*480 and do actually some downscaling when the data goes to display. Depending on what kind of hardware you have (whether it can perform graphics downscaling operations etc), you might want to consider how to downscale (like pixel skipping vs interpolation, basic speed vs quality dilemma). Anyway no matter how you actually scale that thing, you will be still losing pixel data. But again, if your display is half*half of original dimension, the scaling shouldn't be that ugly, especially when the UI graphics are pretty large. -- Kuisma ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] scalability releated things in bugzilla
Hello everybody, as there is ongoing some effort to make the current widgets scaleble, current proposions have made available to the public through the bugzilla: https://maemo.org/bugzilla/buglist.cgi?keywords=scalability The bugs have 'scalability' keyword (as posting this, there is only 2 of those), some might contain information on plans. If you feel like you have some suggestions and you want to affect on the future designs, feel free to have a look and comment/suggest. -- Kuisma ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] scalability: HildonSeekbar
Hi, I've started to see how the Hildon widgets could be improved to scale them better to different kind of devices, started with HildonSeekbar (also done few others too but don't have diffs yet). So there is patch to allow HildonSeekbar theming to adjust it's size in the maemo bugzilla as attachment: https://maemo.org/bugzilla/show_bug.cgi?id=397 If anybody is interested in reviewing and commenting on this patch it would be appreciated. -- Kuisma ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] problems of Instalingl a usb camera for N770
ext [EMAIL PROTECTED] wrote: I just wanted to install usb camera for N770,the model I used is the Logetich quickcam pro4000,the driver is pwc.However when I installed the module pwc.ko ,it says invalid format.Is there anyone have isntalled a usb camera for N770? John Sound like same issue which is with kernel modules in general. Is the module should be compiled against the same kernel which will load the module. So the question is: is the module compiled against the same kernel which is in your 770 (the default 770 kernel unless you have replaced it with your own)? You can find the kernel sources from maemo website with little digging which you can use for compiling the module. Another possible cause could be that the kernel module is not compiled for ARM, which could happen as user mistake or if the kernel module described above is delivered as a binary (just trying to take in account every possible reason)... 100% sure the module is for ARM? -- Kuisma ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] ssh + display
Lassi Syrjälä wrote: Hi, I think you need to: $ . /etc/osso-af-init/af-defines.sh Just as quick comment, if your application uses X, it needs to have DISPLAY defined. If it uses D-BUS in any means (like use libosso), it needs the D-BUS environment variables to be set correctly. If you want GTK to be themed you need to set up GTK2_RC_FILES and so forth. This little script will set up every needed envvar. Just wanted to say that if you have simple custom X application all you need is to have DISPLAY properly set. -- Kuisma ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Installing packages in extra storage?
PS It might be polite to move this conversation to the users list at some point. Just giving a hint (maybe too obvious) to application developers first ;) If your application takes more than 10 megs you could do with default software image (the one averate end users use) this: Application installer installs just few files which include wrapper executable and main program is extracted on a MMC (of course, you could install it also on some other type of mount). Then the wrapper would just check if media is in and launch the application itself, if it's not it it would bitch something like "Correct media not inserted" to user (does this remind you of some proprietary CD games which say something like "Please insert CD this and that"?). I guess this was all Captain Obvious had to say this time... -- Kuisma ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Port of pingu
Oh yes, I forgot to tell the most useful piece of information: To get rid of Xvidemode dependency I had to hack the autoconf file to not depend on it and modify the part of sources which required it. It was basically the resoluation switching (if I remember correctly it was used only for asking for abailable resoluations). Locating of the code is rather simple, since error messages will point you there. What I did was to put there hardcoded resoluation (800*480) instead of asking it from Xvm. That's all I can remember without actual sources :/ -- Kuisma Kuisma Salonen wrote: Hello, I've formatted a harddrive some time ago (and don't have the files right now), but here's a little story: I admit that pingus is a cool game (url is http://pingus.seul.org/ in case somebody does not know) so I have checked how it would port for 770. I was able to compile the clanlib with some sourcecode modifications, but the shared object took more than 10 megs (ok, on MMC this is not that bad + I am not really sure whether it was stripped or not, most likely not). Next was building pingus itself. The problem was that pingus haven't been maintained properly for a loong loong time and it was written for older version of clanlib (which is source uncompatible with the one I managed to build). Then began bigger hell: porting pingus itself. Since it was written for older incompatible version of clanlib I had to start porting it for the version i had (was 0.7.something). Even more awful, clanlib has some new architecture which requires more work. That was something I couldn't finish and it was halfway (or less) done. If (big _IF_) I manage to find the files from backups, I'll upload them somewhere in the case somebody would like to continue where I was left. And yes, I know this soulds little bit like a fish story ;) Anyway, if you want to start from scratch, the path will be long. Plus I am not really sure of gained performance (the screen size is perfect for the game, but not really perfect for the performance). I have this little bad feeling that pingus tries to use page flipping (which works when HW supports such a feature, 770 won't support) so redraws are fullscreen, thus limiting the fps under 20 (+ with all the logic processing and internal draws it has to do it will be less). But like I said in the beginning, porting clanlib is indeed possible. -- Kuisma ext Fred Lefévère-Laaoide wrote: Hi, I'm looking at porting pingu (this nice lemmings clone). It needs Clanlib & Clanllib needs X11/extensions/xf86vmode.h ... Any idea if I'm boarding a boat that will never touch a coast ??? Thanks Fred ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Port of pingu
Hello, I've formatted a harddrive some time ago (and don't have the files right now), but here's a little story: I admit that pingus is a cool game (url is http://pingus.seul.org/ in case somebody does not know) so I have checked how it would port for 770. I was able to compile the clanlib with some sourcecode modifications, but the shared object took more than 10 megs (ok, on MMC this is not that bad + I am not really sure whether it was stripped or not, most likely not). Next was building pingus itself. The problem was that pingus haven't been maintained properly for a loong loong time and it was written for older version of clanlib (which is source uncompatible with the one I managed to build). Then began bigger hell: porting pingus itself. Since it was written for older incompatible version of clanlib I had to start porting it for the version i had (was 0.7.something). Even more awful, clanlib has some new architecture which requires more work. That was something I couldn't finish and it was halfway (or less) done. If (big _IF_) I manage to find the files from backups, I'll upload them somewhere in the case somebody would like to continue where I was left. And yes, I know this soulds little bit like a fish story ;) Anyway, if you want to start from scratch, the path will be long. Plus I am not really sure of gained performance (the screen size is perfect for the game, but not really perfect for the performance). I have this little bad feeling that pingus tries to use page flipping (which works when HW supports such a feature, 770 won't support) so redraws are fullscreen, thus limiting the fps under 20 (+ with all the logic processing and internal draws it has to do it will be less). But like I said in the beginning, porting clanlib is indeed possible. -- Kuisma ext Fred Lefévère-Laaoide wrote: Hi, I'm looking at porting pingu (this nice lemmings clone). It needs Clanlib & Clanllib needs X11/extensions/xf86vmode.h ... Any idea if I'm boarding a boat that will never touch a coast ??? Thanks Fred ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] HW accelerated pixel doubling in SDL games
Hello everybody, there is added to wiki how you could this: https://maemo.org/maemowiki/GameDevelopment It's useful for games which requires more drawing speed than with 800x480 res. This is just again speed vs high res dilemma. If your game doesn't update while screen at time (in terms of SDL this means you use SDL_UpdateRect() functions instead of SDL_Flip()), you probably should still stick with high-res graphics. Of course one alternative is to use both of them inside the game. -- Kuisma ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Sound/music library for use in games on maemo
Hi, currently the situation is not the best one, due to some reasons (I won't be too specific here) the SDL audio relies on ESD which relies on DSP for now. If your game is using SDL, you probably want to use SDL and SDL_Mixer for audio, as they are shipped with the system. Of course you can use for example ESD but it is recommended to use SDL since it's most supported game programming API on the platform, and even if it uses now ESD for audio, it might change in the future to use DSP directly, so when relying on the SDL you wouldn't have to change anything if those will be improved. -Kuisma ext Serge Semashko wrote: Hello, What is the best library for sound/music support in games for maemo platform? Does SDL_Mixer make use of DSP core? I'm just worried about performance a bit. Thanks in advance. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
