| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | Praticamente so jogo quake 3 e nao faco distincao entre linux e windows. Jogo igualmente mal em ambos.
Tenho uma TNT2 em casa e usando os drivers da nvidia (?.1251 no linux e creative-detonator-650 no windows) tenho a volta de 80-90% da performance do windows em linux (800x600@16bits de cor, X 4.0.3, win98). Ambos os quakes (win & linux) partilham (quase) a mesma configuracao e grande parte dos .pk3 gracas aos 'symbolic links'.
Os unicos problemas devem-se a sensibilidade do rato, que varia do win para linux, e a nao existencia um gamepspy para linux (uso o xqf, que faz quase o mesmo).
Para alem disso, instalar os drivers da nvida e um aborrecimento porque nem fazem parte do X nem do kernel. Ainda por cima tenho a sensacao que nao sao tao estaveis como os do windows. Tenho o xdm/kdw/gdm desactivado por causa de bugs nos drivers/PAM/X (???) que me congelavam a maquina.
O linux tem uma vantagem relativa nas maquinas com pouca ram. Arrancando o X em 'failsafe', sem KDE/GNOME ou afins deixa mais memoria disponivel ao quake, traduzindo-se numa melhor velocidade a carregar os niveis/modelos.
Resumindo, linux pode ser quase tao bom como o windows 98 para jogos.
--- |
| | | Games (Pontos:3, Informativo) |
| | Bem, eu jogo Unreal Tournament, Heroes 3, Quake III, Quake II e Quake GL... Sem grande espiga... para além disso tens os velhinhos jogos de arcada com o X MAME... :], se bem que nao te referes a isso... Uso numa maquina 2 Voodoo II em SLI (nem sei se funciona decentemente se não o SLI) com uma Diamond Viper 550, e nao tenho instalados os drivers da Nvidia, uso sempre GLIDE. Na outra máquina tenho uma Asus 3800 que funciona com os drivers da nvidia 0.99 axo, e como já disseram, tirando o comportamento do rato, M$ IntelliExplorer Optical, 0 probs...
--------------------------------------------
If there is such a thing as too much power...
I've not discovered it... |
| | | | | "não tem protected mode e logo tem um acesso mais rápido ao hardware" Saberás ao menos o que significa o protected mode nos processadores ia32? Penso que não... Então uma breve explicação: Os 8086 e todos os processadores seguintes da intel funcionam em real mode, ou seja registos de 16 bits; acesso a apenas um megabyte de memória; tabela de interrupções nos primeiros 1024 bytes da memória; etc. No 80286 a Intel introduziu um novo modo de funcionamento do processador, o protected mode, que já permitia acesso a 16 megabytes, e algumas outras alterações não muito signficativas, mas com o grave problema de não se poder voltar ao real mode. Com o 80836 a Intel colocou-se par a par com os outros fabricantes de hardware, por oferecer MMU com 4 níveis de privilégio, 4Gb de endereçamento (até 16Tb a partir do i686, mas mantendo-se o limite de 4Gb por aplicação), paginação e segmentação, TLBs, GDT, etc, que permitem um SO ser mesmo um SO e não deixar uma aplicação mal comportada destruir todo o sistema... E chega de história, que poderá não estar de todo correcta, faltam-me alguns detalhes do protected mode do 80286), e respondendo à tua pergunta, de que server um Pentium ou Pentium MMX ou Pentium Pro ou Pentium II ou Pentium Celeron ou Pentium III ouK6, K6 2, Thunderbird, Duron, etc, se funcionariam com apenas um megabyte de memória e sem todas as instrucções 32 bits? Mais valia reaproveitar todos os 8086 que andam por aí em museus... O que poderá acontecer será talvez o jogo correr com o nível de privilégio 0, o que duvidaria se a plataforma fosse de uma empresa que soubesse criar OS, mas como tem demonstrado preferir velocidade a segurança (ver a evolução do NT, onde, por exemplo, com o NT4 passaram a colocar vários drivers ao mesmo nível do kernel), talvez até faça isso... De qualquer modo, isso traria uns avanços de performance significantes apenas nas syscalls, em que há mudança de nível de privilégio, e como isso não é comum em jogos (afinal trata-se apenas de usar a placa gráfica), talvez tenham sido razoáveis e mantido as aplicações (ie jogos) no nível 4. É que ficaria muito confuso quando a consola bloqueasse e não se poderia dizer se seria culpa do jogo ou da Microsoft, e assim já se pode culpar quem merece. ;-)
hugs
Strange |
| | | | | | (...)No 80286 a Intel introduziu um novo modo de funcionamento do processador, o protected mode, que já permitia acesso a 16 megabytes, e algumas outras alterações não muito signficativas, mas com o grave problema de não se poder voltar ao real mode.(...)
Penso que o acesso ao protected mode no 286 só se fazia através de um bug no processador, que depois teve de ser mantido. E sim, podia-se voltar ao real mode... com um reset ao processador (alguns BIOS permitiam fazer reset ao processador sem fazer reboot à máquina). Ahhhh... a tecnologia da Intel é linda não é?
-- Carlos Rodrigues
- "I think my men can handle one little penguin!"
- "No, Mr. Gates, your men are already dead!"
|
| | | | | O "bug" a que te referes deve ser o de a linha A20 responder mesmo quando o processador se encontrava em real mode, permitindo o acesso a mais 64k-16 de RAM, a depois chamada de HMA. O uso da HMA obrigou depois o aparecimento do himem.sys para controlar a A20 e o acesso a essa memória. O modo protegido do 286 não era bug, e nem podia ser pois resultou de um redesenho total da lógica do processador. Infelizmente, a mudança tinha que ser radical, pois não havia a emulação de modo real (não me lembro do nome exacto, mas é o v86 usado por exemplo pelo windows nas consolas e pelo linux no dosemu), e não havia modo de retornar a modo real sem o tal reset (btw, reset é igual a reboot, não?). Por isso, nunca ninguém teve a ousadia de usar o modo protegido no 286, pois o SO não o poderia usar sem se atirar para o lixo todos os programas e drivers existentes, e nenhum programa o podia usar pois não havia SO que o suportasse... (Além do minix, claro...)
hugs
Strange |
| | | | Por acaso cometi uma gaffe (é para aprender a não atirar coisas do topo da memória), o tal bug no 286 era o que permitia voltar ao real mode não o que permitia entrar no protected mode.
Mas penso que não cometo outra gaffe ao dizer que o modo vm86 só foi introduzido no 386.
Já agora esta história toda está aqui.
-- Carlos Rodrigues
- "I think my men can handle one little penguin!"
- "No, Mr. Gates, your men are already dead!"
|
| | | | Primeiro, nos 286 para voltar ao modo real era preciso fazer um reset ao CPU (mas não ao computador todo) uma vez que não existia uma intrução para isso. Há uma técnica muito gira para isso...
Quanto à possibilidade de o CPU aceder a memória acima do primeiro MB em modo real, à duas coisas: O facto de o processador fazer os cálculos dos endereços em 32 bits em vez de 20 mesmo em modo real, o que obrigou a IBM a criar um modo externo de desligar a linha A20 (21º bit de endereço) para que os endereços "dêm a volta" como num 8086. O facto de o processador não fazer reset à GDT, que permite ir para modo protegido, alterar a GDT e ficar segmentos com bases e tamanhos diferentes dos habituais em modo real (segmentos de 64 kB, a começar a cada 16*N bytes). Este modo é conhecido por unreal mode.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | | "Quanto à possibilidade de o CPU aceder a memória acima do primeiro MB em modo real, à duas coisas:" Então há três coisas, as duas que explicaste que eu desconhecia, e a que era usada: Diferente do 8086 que tinha apenas 20 linhas de endereçamento (0-19, 2^20 = 1Mb), o 80286 tinha mais 4 linhas (20-23, 2^24 = 16Mb). Agora, o "bug" engraçado era devido ao modo de endereçamento de memória: segmento * 16 + deslocamento. Como os registos eram de 16 bits, isso dava 20 bits (16+4) mais o deslocamento, resultando em se poder aceder desde 0x00000 até 0x0ffff0 + 0xffff = 0x10ffef = 1Mb + 65519b (HMA). É claro que isto já devia ser conhecido, mas como o 8086 apenas tinha 16 linhas de endereçamento, continuávamos com 1Mb, o espanto foi que no 80286, mesmo em modo real, a linha A20 respondia! E pronto, mesmo com um SIMM de apenas um 1Mb, tinhamos acesso a mais 64kb, já que a maior parte da memória de 640Kb para cima estava reservada para a BIOS, memória gráfica e outras BIOSes
hugs
Strange |
| | | | O primeiro ponto era exactamente esse.
SEGMENT:OFFSET -> (SEGMNT >> 4) + OFFSET
Logo, 0xFFFF:0xFFFF => 0x10FFEF
0x10FFEF precisa de 21 bits para ser representado mas nos 8086 só havia 20 (A0-A19), logo o 21º bit era ignorado e 0xFFFF:0xFFFF correspondia ao endereço físico 0x0FFEF.
Nos 286 e 386+ usam-se 24 e 32 bits respectivamente para os endereços. Como o processador faz o cálculo do endereço físico da mesma maneira em modo real e protegido (o que também contribui para o segundo truque que eu apontei), 0xFFFF:0xFFFF corresponde ao endereço físico 0x10FFEF.
Como alguma aplicações aproveitavam aquela característica dos 8086 (e 80186 também), a IBM foi obrigada a colocar um dispositivo externo ao processador que fixa a linha A20 (21º bit de endereço) a 0, entre o CPU e a memória.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | | "O que poderá acontecer será talvez o jogo correr com o nível de privilégio 0, [...], mas como tem demonstrado preferir velocidade a segurança [..] talvez até faça isso..." Se a memória não me falha, no Win9X, o próprio código do kernel é que está a correr em nível 3, permitindo assim um "maior performance" (e tb mais reboot/seg).
Flip |
| | | | | O kernel tem que correr em nível 0, que é o nível de maior privilégio, logo específico para o kernel. E normalmente nenhum SO usa os níveis 1, 2 e 3, por uma questão de portabilidade (apenas a Intel usa os 4, as outras arquitecturas usam apenas 2 níveis); apenas vem complicar o desenho do sistema; e finalmente não traz vantagens de performance (mais uma troca de nível a atrapalhar) e poucas de segurança.
hugs
Strange |
| | | | Fiquei xateado nao poder por a minha voodoo2 a dar com a ultima distribuicao do Mandrake 8.0 a versao anterior ate trazia o glide, e funcionava mal instalado ... mas agora :|, tow ways instalo a versao anterior Mandrake 7.2 or compilo a kernel da versao 7.2 .... any thoughts ?
|
| | | | Nao sei se ja tiveram este problema:
Tenho uma G-force2MX com os drivers 1.0 (ou .1241, e' como preferirem)da nvidia.
O quake3 fica-me ao nivel do windos em single player...
... mas em multiplayer fica um nojo!!! Ainda nao falei com alguem que tenha tido o mesmo problema, por isso, venham dai as vossas experiencias. :)
Cumps.
It doesn't matter who made it... It matters who got the idea (monk) |
| | | | | Eu não me posso pronunciar sobre Quake 3 porque não tenho isso em Linux mas tenho algo semelhante: Unreal Tournament. Também disponho de uma GeForce 2 MX e há diferença entre o Direct 3D no Windows e o OpenGL no Linux em single player... em Linux o jogo e/ou os níveis carregam em metade do tempo.
Obviamente que para isto funcionar assim tenho que ter as texturas comprimidas (que estão disponíveis no 2º CD do jogo) instaladas. Quanto ao jogo on-line sinceramente estou meio confuso. Embora as informações indiquem que estou a obter 50/60 fps nota-se uma falta de fluidez incrível.
Já discuti isto com outras pessoas qu também jogam UT e há um dado curioso a acrescentar: esta situação do jogo perder fluidez (ou fps em alguns casos) verifica-se apenas quando se joga na internet e não em LAN. Não estamos obviamente a falar de problemas de ping alto ou packet loss mas sim de qualquer outro problema que causa perda de performance. O problema tem, ao que parece, vindo a diminuir a cada nova versão dos drivers da nvidia mas suspeito que a origem do mesmo não resida só aí... Por estes lados este é o ponto da situação... PS: Já muitas pessoas perguntaram o que é isso do 2º CD do Unreal e das texturas comprimidas... basicamente a altereção em Linux é simples:
1º - Copiam-se as texturas do 2º CD para o directório qq-coisa-aqui-conforme-instalação/ut/Textures 2º - Edita-se o ficheiro /home/user-aqui/.loki/ut/System/UnrealTournament.ini.
Aqui é um pouco mais demorado: há que mudar os render devices e afins (quase no início do ficheiro) para OpenGLDrv.RenderDevice ou algo parecido. Depois na seccção desse OpenGL (muito mais abaixo no mesmo ficheiro) e onde está S3TC=0 mudar para S3TC=1 3º Correr o jogo em 32-bit de cor.
Em princípio a profundidade de cor do X não deve interferir mas só testei com o X a correr em 24-bit... importante mesmo são os 32-bit no jogo senão o trabalho todo não produz efeitos. Bom jogo! :-)
|
| | | | | ... e depois de todo este desfilar de alta tecnologia resta talvez aconselhar o Linux como excelente plataforma também para jogar Nethack. O grafismo no écran (para não falar das imagens imaginadas, para jogadores com os plugins apropriados) é espectacularmente realista: depois de alguns dias de jogo, um "f" branquinho é mesmo a imagem de um gato. O suporte para o revolucionário mecanismo de input (teclado) é também fenomenal. O jogo funciona tão bem como ou melhor do que em DOS ou Windows. E nem sequer me estou a referir às interfaces gráficas entretanto criadas (depois de as ter visto continuo a preferir jogar como @) :-) xterm -bg black -fg ivory2 -bg black -cr gold -fn -misc-fixed-medium-r-normal-*-*-120-*-*-c-*-iso8859-1 -ms brown -T NetHack -name NetHack -xrm "*decTerminalID: 220" -xrm "XTerm.pointerColorBackground: black" -e nethack
|
| | | | | | E todos aqueles que deliram com Mud's ?? Apenas instalar o tiny fugue ou um cliente a seu gosto... Até uma banhosa de uma placa com 2Mb PCI dá para isso ;}
--------------------------------------------
If there is such a thing as too much power...
I've not discovered it... |
| | | | | Eu sou um jogador assíduo de quake2 na internet (Oi , ashnazg! ;)). Infelizmente, até a muito pouco tempo não tinha uma placa com suporte para opengl em Linux. Agora, já tenho mas ainda não tive pachorra para tratar disso pelo que tenho continuado a jogar em win$. No entanto pelas minhas experiências pude verificar que a minha ligação é melhor para jogar na net quando estou em Linux e isso para mim é importante. Vi que toda gente estava preocupada com os fps mas e o ping? Mais alguém teve a senação de melhoria da ligação a net para jogos quando jogados em Linux? Fquem bem!
JP
|
| |
|
