Quote from: kevlarman on September 19, 2008, 04:55:06 PM
Quote from: silverbak on September 19, 2008, 04:19:13 PM
Ok tremulous works, in that I can actually play it.
It loads all my old settings from my old configuration file and it runs at 1280x1024 etc.
There's just one problem, the graphics look like they are REALLY low resolution. I even tried moving my cfg file out the way and letting it regenerate in case that was the problem but the issue remains in either case.
Any insight as to why this occurs with this build? Incidentally, if I use the Debian executable the graphics are just fine.
I've got a feeling I won't be playing trem until verision 1.2 at this rate as it's just becoming an outright hassle.
r_width 1280; r_height 1024
the configuration for resolution changed in svn.
those changes has been reverted in tremwars client server fsm-trem and tremfusion you should consider doing the same its better when the ui works
Quote from: SlackerLinux on September 19, 2008, 05:05:25 PM
Quote from: kevlarman on September 19, 2008, 04:55:06 PM
Quote from: silverbak on September 19, 2008, 04:19:13 PM
Ok tremulous works, in that I can actually play it.
It loads all my old settings from my old configuration file and it runs at 1280x1024 etc.
There's just one problem, the graphics look like they are REALLY low resolution. I even tried moving my cfg file out the way and letting it regenerate in case that was the problem but the issue remains in either case.
Any insight as to why this occurs with this build? Incidentally, if I use the Debian executable the graphics are just fine.
I've got a feeling I won't be playing trem until verision 1.2 at this rate as it's just becoming an outright hassle.
r_width 1280; r_height 1024
the configuration for resolution changed in svn.
those changes has been reverted in tremwars client server fsm-trem and tremfusion you should consider doing the same its better when the ui works
they aren't reverted in tremfusion, there's a hack that makes the menu work.
Do you really need to insert statements about awesomeness of fsm/tremfusion?
Apparently as often as possible, regardless of relevance :P
Quote from: Rocinante on September 19, 2008, 08:13:14 PM
Apparently as often as possible, regardless of relevance :P
well its not gonna advertise itself :) anyway not reverting it or not having a compatibility layer will only make noobs go wtf my menus don't work hate you long time.
Quote from: Rocinante on September 19, 2008, 08:13:14 PM
Apparently as often as possible, regardless of relevance :P
David and kevlarman do it for mgclient. >:( So why not others? :P
Quote from: Amanieu on September 20, 2008, 05:57:56 AM
Quote from: Rocinante on September 19, 2008, 08:13:14 PM
Apparently as often as possible, regardless of relevance :P
David and kevlarman do it for mgclient. >:( So why not others? :P
i'm not advertising mgclient, i chose the client with the fewest useless features (broken bloom in this case) that fit the requirements (being recent enough to include the x86_64 jit qvm compiler)
Quote from: kevlarman on September 20, 2008, 07:25:11 AM
i'm not advertising mgclient, i chose the client with the fewest useless features (broken bloom in this case) that fit the requirements (being recent enough to include the x86_64 jit qvm compiler)
Which is advertising the mgclient.
Quote from: Amanieu on September 20, 2008, 07:59:47 AM
Quote from: kevlarman on September 20, 2008, 07:25:11 AM
i'm not advertising mgclient, i chose the client with the fewest useless features (broken bloom in this case) that fit the requirements (being recent enough to include the x86_64 jit qvm compiler)
Which is advertising the mgclient.
but mgclient is not a fork... and it is somehow official
I suggest you to advertise in your own forum
Quote from: fingered banana on September 20, 2008, 08:17:53 AM
Quote from: Amanieu on September 20, 2008, 07:59:47 AM
Quote from: kevlarman on September 20, 2008, 07:25:11 AM
i'm not advertising mgclient, i chose the client with the fewest useless features (broken bloom in this case) that fit the requirements (being recent enough to include the x86_64 jit qvm compiler)
Which is advertising the mgclient.
but mgclient is not a fork... and it is somehow official
I suggest you to advertise in your own forum
mg client is as official as fsm-trem tremfusion tw-client server tremulous-amanieu tjw
in other words it isn't official its just a custom client like the rest
Quote from: SlackerLinux on September 20, 2008, 08:40:39 AM
Quote from: fingered banana on September 20, 2008, 08:17:53 AM
Quote from: Amanieu on September 20, 2008, 07:59:47 AM
Quote from: kevlarman on September 20, 2008, 07:25:11 AM
i'm not advertising mgclient, i chose the client with the fewest useless features (broken bloom in this case) that fit the requirements (being recent enough to include the x86_64 jit qvm compiler)
Which is advertising the mgclient.
but mgclient is not a fork... and it is somehow official
I suggest you to advertise in your own forum
mg client is as official as fsm-trem tremfusion tw-client server tremulous-amanieu tjw
in other words it isn't official its just a custom client like the rest
ROFL. It is done by people in the development team. Clearly official compared to your bloated forks.
TJW's is official, none others are.
Quote from: fingered banana on September 20, 2008, 09:21:43 AM
Quote from: SlackerLinux on September 20, 2008, 08:40:39 AM
Quote from: fingered banana on September 20, 2008, 08:17:53 AM
Quote from: Amanieu on September 20, 2008, 07:59:47 AM
Quote from: kevlarman on September 20, 2008, 07:25:11 AM
i'm not advertising mgclient, i chose the client with the fewest useless features (broken bloom in this case) that fit the requirements (being recent enough to include the x86_64 jit qvm compiler)
Which is advertising the mgclient.
but mgclient is not a fork... and it is somehow official
I suggest you to advertise in your own forum
mg client is as official as fsm-trem tremfusion tw-client server tremulous-amanieu tjw
in other words it isn't official its just a custom client like the rest
ROFL. It is done by people in the development team. Clearly official compared to your bloated forks.
fsm-trem isnt a FORK its a client and its not bloated we have kept out alot of stuff
mg devs are not the tremulous devs do they have svn commit access i think not (1 or 2 might) there just like us doing work and providing it for possible inclusion. i dont really like mg's attitude to other projects expecially when they talk about tremfusion.
Quote from: David on September 20, 2008, 10:38:45 AM
TJW's is official, none others are.
although its from a developer its still not ''official'' its just what everyone points newbies to. if it was official it would be labeled tremulous 1.1.1
Quote from: kevlarman on September 20, 2008, 07:25:11 AM
Quote from: Amanieu on September 20, 2008, 05:57:56 AM
Quote from: Rocinante on September 19, 2008, 08:13:14 PM
Apparently as often as possible, regardless of relevance :P
David and kevlarman do it for mgclient. >:( So why not others? :P
i'm not advertising mgclient, i chose the client with the fewest useless features (broken bloom in this case) that fit the requirements (being recent enough to include the x86_64 jit qvm compiler)
have you tried the oa version of bloom it isn't that evil framebuffer version that crashes.
Quote from: SlackerLinux on September 20, 2008, 12:49:46 PM
i dont really like mg's attitude to other projects expecially when they talk about tremfusion.
And I personally don't like their attitude about the users and the community, and their blatant plans to take over and try to rule the Tremulous universe because they're unhappy with what's going on. Notice I said *personally*. As has been said by many people over and over, no one person speaks for Mercenaries Guild, any more than my status as a moderator means I speak for all moderators when I say something.
Though I will say as a moderator, that none of this shit has anything to do with building a 64-bit client with a GUID, SMP and no SDL. Since that question was asked, and so that the question and answer isn't lost, I'll split off all this shit instead of locking the whole damned thread.