Re: evstack, Results of multi-headed quake test, and input fun
Well - I'm not joseph, but it's as simple as: "fov degrees" Only problem is, that it causes some strange distortion... Please describe "strange". Screenshots would be nifty. I have tried with the original DOS version. Looks like through a fisheye lens, which is basically right, but not the intended thing, as vertical distortion is way too high, if you imagine it played on two monitors side-by side. I'll have a look at the quakeforge realease some time soon. Does it allow "strange" resolutions like 1920x480 ? CU, ANdy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: evstack, Results of multi-headed quake test, and input fun
Joseph Carter wrote: I play at fov 145.. Other than not having guns drawn in the software renderer, whatever "strangeness" there is I consider to be normal, unless there's something in particular the ggi target does that I don't know about. I consider the distortions of displaying _any_ FOV on a flat screen normal, just those distortions become greater above 90 degrees, and become "strange" as you approach or pass 180, and start to mess with my head at 360. As for the GGI target, I'm sure it is doing the right thing, but I haven't tried it, as I have never played Quake in my life. I'm just speaking of large FOV projections on planar surfaces in general.
Re: evstack, Results of multi-headed quake test, and input fun
On Fri, Feb 18, 2000 at 05:15:52PM +, Justin Cormack wrote: The really cool thing would be, if you could give the angles at which the individual monitors are to quake, and it would render an individual picture for each one. You can write that code, I sure don't plan on it. ; I do actually plan on writing this, for various reasons, just as soon as I get time. I look forward to seeing the results! Hardware acceleration ffor 3D is needed before you can do the really useful stuff though. Agreed. -- Joseph Carter [EMAIL PROTECTED] Debian Linux developer http://tank.debian.net GnuPG key pub 1024D/DCF9DAB3 sub 2048g/3F9C2A43 http://www.debian.org20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 "What is striking, however, is the general layout and integration of the system. Debian is a truly elegant Linux distribution; great care has been taken in the preparation of packages and their placement within the system. The sheer number of packages available is also impressive"
GGI web browser
This is just in case someone is really desperated for a GGI web browser: I just bumped into ZEN, a web browser that works in fbdev, but it does not use GGI. If someone has time to spare maybe a little hack on zen could result in a GGI browser. Cheers, -- Cesar Augusto Rorato Crusius o__ o__ o__ o__ o__ Stanford University ,/'_ ,/'_ ,/'_ ,/'_ ,/'_ e-mail:[EMAIL PROTECTED](_)\(_) (_)\(_) (_)\(_) (_)\(_) (_)\(_) www.stanford.edu/~crusius HE WHO SACRIFICES FUNCTIONALITY FOR EASE OF USE LOSES BOTH AND DESERVES NEITHER
Re: Multi-head HOWTO
Joseph Carter [EMAIL PROTECTED] writes: That's fine, and a good default. If the application wants to grab the mouse, it should request to do so specifically.. The point is - why whould an application designed to run fullscreen (which all LibGGI apps are by definition) ever want to "grab the mouse" ? I think there ought to be a method for the application to grab the mouse. QuakeForge has a method for this under its option menu which isn't present for the GGI target. However I'm considering adding functionality to do this. Mainly because no Quakeforge target should be better than the GGI one. ;-) The idea is that we do it with *SendEvent() and GII_CMDCODE_PREFER_RELCOORD and GII_CMDCODE_PREFER_ABSCOORD, and thus make it a quite useful functionality for non-games also. This way we also doesn't add a single byte of code to inputs that don't have functionality to do this. What do you think Andy? Sounds good? //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: GGI web browser
On Fri, 18 Feb 2000, Cesar Crusius wrote: This is just in case someone is really desperated for a GGI web browser: I just bumped into ZEN, a web browser that works in fbdev, but it does not use GGI. If someone has time to spare maybe a little hack on zen could result in a GGI browser. Right. WHERE IS IT :) I wanna hack a WWW browser... G'day, eh? :) - Teunis
Re: GGI web browser
On Fri, 18 Feb 2000, Cesar Crusius wrote: * teunis ([EMAIL PROTECTED]) [000218 13:55]: On Fri, 18 Feb 2000, Cesar Crusius wrote: This is just in case someone is really desperated for a GGI web browser: I just bumped into ZEN, a web browser that works in fbdev, but it does not use GGI. If someone has time to spare maybe a little hack on zen could result in a GGI browser. Right. WHERE IS IT :) I wanna hack a WWW browser... There you go: http://www.nocrew.org/software/zen I contacted the author, he will be happy to help anyone doing such a thing. Another idea, maybe better, would be to hack lynx... Starting to play... *giggle* Anyways, I like Lynx (and w3m for that matter) ... but graphics have more potential than text for many things. And I don't really like most of the -network- layer of lynx although it works.. (or the processing layer. w3m is superior for handling html although it has interface weaknesses :) More later... G'day, eh? :) - Teunis
that ggiplay I've been working on...
is on hold a wee bit. I've discovered a -lot- of problems in the threading. And haven't traced them yet. For some reason pthreads is losing condition signals. Anyone know anything about this? (If anyone's tried it and lost audio, that's why) So I'm moving to a multitasking model now, following The Unix Way :) Anyways, I've discovered that while Windows-style messaging is cute it doesn't really work on a secure system (anyone surprised?) On a whim I decided to attempt a Windows-style GUI under linux and it flopped. *giggle* (Thought I'd implement a Windows Media system under linux/GGI :) ...failed *sigh* Sooo Anyone know how to do memory locking/synchronization between processes? I'm still dithering... G'day, eh? :) - Teunis
Re: Multi-head HOWTO
On Fri, Feb 18, 2000 at 10:48:50PM +0100, Marcus Sundberg wrote: That's fine, and a good default. If the application wants to grab the mouse, it should request to do so specifically.. The point is - why whould an application designed to run fullscreen (which all LibGGI apps are by definition) ever want to "grab the mouse" ? Think fbdev... I think there ought to be a method for the application to grab the mouse. QuakeForge has a method for this under its option menu which isn't present for the GGI target. However I'm considering adding functionality to do this. Mainly because no Quakeforge target should be better than the GGI one. ;-) I will admit, before Mercury broke the input code for every target, -ggi was my standard "I have no idea if this is gonna work or not" testbed, mostly because it's the most likely to actually work first, and second it's the most likely not to hose my box if it doesn't. = I think GII is useful even in places where GGI isn't, personally. -- Joseph Carter [EMAIL PROTECTED] Debian Linux developer http://tank.debian.net GnuPG key pub 1024D/DCF9DAB3 sub 2048g/3F9C2A43 http://www.debian.org20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 rcw dark: caldera? Knghtbrd rcw - that's not a distribution, it's a curse rcw Knghtbrd: it's a cursed distribution
Re: Multiple windows??
Is it possible with GGI to create a window (if the target supports it, for example X)? Sure. That is what LibGGI does on windowed targets. And if not, would it ever be possible to run gdk apps over ggi? In principle yes. Just need to port gdk to use GGI. CU, ANdy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: Multi-head HOWTO
I think there ought to be a method for the application to grab the mouse. QuakeForge has a method for this under its option menu which isn't present for the GGI target. However I'm considering adding functionality to do this. Mainly because no Quakeforge target should be better than the GGI one. ;-) ROTFL ... The idea is that we do it with *SendEvent() and GII_CMDCODE_PREFER_RELCOORD and GII_CMDCODE_PREFER_ABSCOORD, and thus make it a quite useful functionality for non-games also. Yes. This way we also doesn't add a single byte of code to inputs that don't have functionality to do this. What do you think Andy? Sounds good? Yeah ... Definitely. I'm just pondering the thought, if we should add that functionality to LibWMH, as it is designed to do the windowing-related stuff, but on the other hand it doesn't quite seem to be the right place ... However it would have the advantage of knowing what target it is running on (as it is an extension) and thus be able to only send the codes when the functionality is available and give nice error codes, if not. This way we could keep the call a private feature of the X input libs (i.e. we don't need to alloc from the public command numberspace). While someone does that, he might as well want to introduce a method to define the cursor shape of the window system in use. That would be very handy for a GUI toolkit, as you could then avoid the use of soft cursors when running on a window system. Marcus: Just decide what you like better. Both implementation possibilities (straight away as commands for direct application use or via LibWMH) seem o.k., so just do the one you like better. CU, ANdy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
porting
what is need to port ggi to the aros (an amiga os clone) to run the 3D cube demo?Jaime Dias
GFI (exists)
Just another software link: I just found out that there exists a generic font interface. It goes under the name VFlib (a brief search in google will lead you there) - you just initialize the library, open a font file (with one call to the same function for every format) and get a bitmapped character for any resolution also with just one function call. I thought this may be of your interest because printing strings with GGI right now is not very powerful. With VFlib it becomes easy to add any type of font rendering to it (Adobe Type1 with antialiasing, TrueType, PK, PCF, etc). Cheers, -- Cesar Augusto Rorato Crusius o__ o__ o__ o__ o__ Stanford University ,/'_ ,/'_ ,/'_ ,/'_ ,/'_ e-mail:[EMAIL PROTECTED](_)\(_) (_)\(_) (_)\(_) (_)\(_) (_)\(_) www.stanford.edu/~crusius HE WHO SACRIFICES FUNCTIONALITY FOR EASE OF USE LOSES BOTH AND DESERVES NEITHER
