LnxSlck
Power Member
Epá... esta respota... LOLOLOL!É melhor ficarmos por aqui.
Não sei porquê. Foi das respostas mais inteligentes que vi há muito tempo.
Querem jogar jogos? Comprem consolas.
Wine - Tópico Geral
- Autor do tópico esquiso
- Data Início
Não sei porquê. Foi das respostas mais inteligentes que vi há muito tempo.
Querem jogar jogos? Comprem consolas.
muddymind
1st Folding then Sex
Se te deres um pouco ao trabalho de ler a thread em condições vais perceber o sentido da minha resposta
(sou um incompreendido )
INDRO
Power Member
Isso depende das pessoas, para mim nada como jogar no PC e muita gente acha o mesmo
Jogar um FPS decente numa consola é horrível, mods/skins/tweaks/etc são mais facilmente feitos num PC (nem sei se é possível na consola), o poder gráfico das gráficas actuais para PC actuais envergonham qualquer consola existente and soo on...
Dat55
Power Member
mods/skins/tweaks, não são permitidos nas consolasIsso depende das pessoas, para mim nada como jogar no PC e muita gente acha o mesmo
Jogar um FPS decente numa consola é horrível, mods/skins/tweaks/etc são mais facilmente feitos num PC (nem sei se é possível na consola), o poder gráfico das gráficas actuais para PC actuais envergonham qualquer consola existente and soo on...
Eu só gostava era que o wine funcionasse como deve de ser no Ubuntu 12.04 64bits, porque compilar à mão é impossível...
Qual é o teu problema?? Tenho o Office 2010, o Diablo II (remebering the good old days) e o Plant´s vs Zombies (só para matar o tempo) a funcionar no Ubuntu 12.04 64bits. Se não me engano já é a versão 1.5.x e também tenho a ultima versão estável do PlayonLinux. Só o Diablo é que não tem som infelizmente, mas nada que me importe muito!
Cumps
Para jogar League of Legends ou Diablo 3 é preciso aplicar patches ao wine. Mas para aplicar patches é preciso aplicá-los ao source code e depois compilarmos nós. O problema é que faltam dependências nos repositórios do Ubuntu 12.04 para o wine 32 bits que são precisos, pelo que não dá para compilar.
Link para o bug: https://bugs.launchpad.net/ubuntu/+source/wine1.4/+bug/944321
Arucard1983
Power Member
Mantendo a tradição que foi a apresentação do Wine 1.4, eu anuncio que já foi lançado o primeiro release candidate do Wine 1.6 que representa o 3º estádio de desenvolvimento após o Wine alcançar a primeira versão estável.
Durante estes meses todos em que decorria as versões de desenvolvimento 1.5.x, no mundo Linux ocorrerem várias coisas, tais como:
- O lançamento de alguns jogos nativos para Linux.
- O lançamento do Darling (que já veio atrasado para o meu gosto), que habilitou a execução de programas Mac OS X em Linux, se bem que está ainda num estado alpha...
- Por fim, lançaram este mês o primeiro emulador Android decente para Linux que permite correr aplicações deste sistema operativo numa máquina Linux Desktop, útil para quem utilize aplicações como complemento. (AndroVM foi o protótipo, agora é o GenyMotion)
Suspeito que a versão 1.6 seja a escolhida para criar uma versão oficial para Android, o problema é que como será escolhido e implementado o emulador x86 para os tablets (maioritários) ARM. Mesmo quando foi apresentado no FOSDEM o protótipo do Wine para Android, já existia na Google Play um emulador para correr alguns jogos (que são exactamente dois oficialmente suportados: Caeser III e Starcraft: Broody War 1.663) baseados no Windows em tablets Android: o programa Winulator.
O Winulator baseia parcialmente no source-code de uma porção do DirectX antigo (3 a 7) de acordo com o Wine, mais o trabalho do próprio autor em complementar algumas funções do WIN32 API. No entanto a grande diferença é este programa actua mais como um launcher sobre uma versão minimalista nativa em ARM do wrapper mini-DX7 para Open GL ES 2.0, acoplado com um emulador tipo binary translator/dynamic recompiler que faria a recompilação do executável do jogo (x86) num macro-código ARM na altura do lançamento da execução do jogo. Desta forma, o overhead entre arquitecturas foi minimizado e jogos que requerem pelo menos um Pentium MMX para terem um desempenho adequado podem ser executados num chip ARM dual e quad-core.
(Infelizmente o segredo daquela aplicação era mesmo o JIT x86/ARM, pelo que seria improvável que o autor cedesse o código-fonte para fundir com o Wine para Android, embora fosse o passo mais coerente, visto que o autor verificou que era impossível suster sozinho o desenvolvimento do Winulator sem fundi-lo com o Wine.)
O Wine para Android irá resolver um problema fulcral do Winulator, visto que suportará as aplicações Desktop GDI e o DirectX, ao contrário do Winulator que requeria o rip da pasta do jogo do computador para o tablet, e só suportava o Direct3D em full-screen. Mas dificilmente o Wine superaria o módulo dos controlos que emulam parte das acções do rato que o Winulator possui (pois o seu objectivo era correr alguns jogos do Windows antigos, e não o Word!).
Embora o lançamento do Wine para Android será uma aplicação claramente disruptiva, o nosso interesse é destacar as novidades do Wine 1.6 que só serão aproveitadas devidamente em máquinas x86 baseadas em Linux ou Mac OS X. (A versão para Android não será provavelmente um port 1:1, pois dificilmente existem funções que nem a emulação x86/ARM daria remotamente qualquer rendimento palpável, salvo os tablets x86 com Android que vão surgindo recentemente).
O Wine 1.6 apresenta algumas novidades que são fulcrais (como a ênfase na versão Android que não é inocente de todo), dos quais destacamos:
- A arquitectura ARM é oficialmente suportada, embora na prática não tenha maior usuabilidade que servir de ferramenta de compilação de algum software Windows em máquinas Linux ARM. A versão para Android é derivada deste esforço. Para resolver fica a questão da emulação x86.
- O Wine para Mac OS X ganhou um driver nativo para o Cocoa API, substituindo a necessidade do X11.app para instalar e executar o Wine. Portanto as aplicações Windows no Mac OS X utilizam agora o Quartz API nativamente para o funcionamento deste emulador.
(Entretanto o suporte para X11.app ainda é mantido como opção caso ocorra problemas com o driver nativo.)
- O trabalho na emulação do Direct3D prosseguiu no último ano, destacando a implementação do próprio compilador de shaders e pipelines que pretende reduzir o overhead, e resolver alguns dos problemas de quebra de frame-rates em jogos exigentes graficamente.
- O trabalho na implementação do Directx 10 e 11 andou um bocado parado
, o que motivou a mobilização por parte da Codeweavers (que lança as versões comerciais do Wine com adições proprietárias) para que a equipa do Wine trabalha-se internamente na implementação do DirectX 11. O Directx 10 já uns 75% implementado, mas falta funções da interface para ser activado. Espera-se que na versão 1.8 já seja possível correr jogos DX10 e DX11, pois prevê-se que o DX9 seja gradualmente abandonado no próximo ano. (A vinda das novas consolas baseadas no DX11 vão estimular o abandono no antigo DX9).
- O Wine possui dois componentes autónomos: o Wine Internet Explorer (um wrapper MSHTML sobre o Gecko) e o Wine Mono (a implementação do .NET), que ainda não são suficientemente maduros para substituir a implementação nativa da Microsoft.
- Especula-se que uma terceira componente esteja na forja, que não é nada mais, nada menos que implementar o WinRT
, habilitando a execução de Aplicações Metro pelo Wine. (evidentemente que não será pela Windows Store...)
Isto porque andaram a implementar as dll que surgiram com o Windows 8, e formam a base do WinRT (aparte do .NET que do qual é a linguagem padrão desta API)
- Também registaram correcções de bugs, completaram funções quebradas e deram continuidade a um projecto interno que estava ainda mais parado que o DX10 (que recomeçou ao cair do pano
): o suporte a controladores nativos do Windows para certos dispositivos USB.
- Isto porque foi implementado no rc1 as primeiras funções relacionadas com o registo e instalação de controladores, que no Wine somente serão suportados controladores para dispositivos USB que operam no user-mode. (O Darling aparentemente suportará uma maior gama de controladores USB, visto que o IOKit é uma bibliotecas Unix-like e portanto mais fácil de sincronizar com o udev). Esta funcionalidade estará mais virada para dispositivos simples que são acompanhados com determinado software: como é o caso dos smartphones que utilizam software Windows para actualizar o seu firmware. (Não esperem que isso vá funcionar na versão 1.8!)
Em suma o lançamento do Wine 1.6 é mais uma versão de consolidação, mas com uma aposta clara para uma nova gama de dispositivos (os tablets Android e computadores ARM), e com o objectivo claro que preparar a versão oficial para o Mac OS X.
Durante estes meses todos em que decorria as versões de desenvolvimento 1.5.x, no mundo Linux ocorrerem várias coisas, tais como:
- O lançamento de alguns jogos nativos para Linux.
- O lançamento do Darling (que já veio atrasado para o meu gosto
), que habilitou a execução de programas Mac OS X em Linux, se bem que está ainda num estado alpha...- Por fim, lançaram este mês o primeiro emulador Android decente para Linux que permite correr aplicações deste sistema operativo numa máquina Linux Desktop, útil para quem utilize aplicações como complemento. (AndroVM foi o protótipo, agora é o GenyMotion
)Suspeito que a versão 1.6 seja a escolhida para criar uma versão oficial para Android, o problema é que como será escolhido e implementado o emulador x86 para os tablets (maioritários) ARM. Mesmo quando foi apresentado no FOSDEM o protótipo do Wine para Android, já existia na Google Play um emulador para correr alguns jogos (que são exactamente dois oficialmente suportados: Caeser III e Starcraft: Broody War 1.663) baseados no Windows em tablets Android: o programa Winulator.
O Winulator baseia parcialmente no source-code de uma porção do DirectX antigo (3 a 7) de acordo com o Wine, mais o trabalho do próprio autor em complementar algumas funções do WIN32 API. No entanto a grande diferença é este programa actua mais como um launcher sobre uma versão minimalista nativa em ARM do wrapper mini-DX7 para Open GL ES 2.0, acoplado com um emulador tipo binary translator/dynamic recompiler que faria a recompilação do executável do jogo (x86) num macro-código ARM na altura do lançamento da execução do jogo. Desta forma, o overhead entre arquitecturas foi minimizado e jogos que requerem pelo menos um Pentium MMX para terem um desempenho adequado podem ser executados num chip ARM dual e quad-core.
(Infelizmente o segredo daquela aplicação era mesmo o JIT x86/ARM, pelo que seria improvável que o autor cedesse o código-fonte para fundir com o Wine para Android, embora fosse o passo mais coerente, visto que o autor verificou que era impossível suster sozinho o desenvolvimento do Winulator sem fundi-lo com o Wine.
)O Wine para Android irá resolver um problema fulcral do Winulator, visto que suportará as aplicações Desktop GDI e o DirectX, ao contrário do Winulator que requeria o rip da pasta do jogo do computador para o tablet, e só suportava o Direct3D em full-screen. Mas dificilmente o Wine superaria o módulo dos controlos que emulam parte das acções do rato que o Winulator possui (pois o seu objectivo era correr alguns jogos do Windows antigos, e não o Word!).
Embora o lançamento do Wine para Android será uma aplicação claramente disruptiva, o nosso interesse é destacar as novidades do Wine 1.6 que só serão aproveitadas devidamente em máquinas x86 baseadas em Linux ou Mac OS X. (A versão para Android não será provavelmente um port 1:1, pois dificilmente existem funções que nem a emulação x86/ARM daria remotamente qualquer rendimento palpável, salvo os tablets x86 com Android que vão surgindo recentemente).
O Wine 1.6 apresenta algumas novidades que são fulcrais (como a ênfase na versão Android que não é inocente de todo), dos quais destacamos:
- A arquitectura ARM é oficialmente suportada, embora na prática não tenha maior usuabilidade que servir de ferramenta de compilação de algum software Windows em máquinas Linux ARM. A versão para Android é derivada deste esforço. Para resolver fica a questão da emulação x86.
- O Wine para Mac OS X ganhou um driver nativo para o Cocoa API, substituindo a necessidade do X11.app para instalar e executar o Wine. Portanto as aplicações Windows no Mac OS X utilizam agora o Quartz API nativamente para o funcionamento deste emulador.
(Entretanto o suporte para X11.app ainda é mantido como opção caso ocorra problemas com o driver nativo.)
- O trabalho na emulação do Direct3D prosseguiu no último ano, destacando a implementação do próprio compilador de shaders e pipelines que pretende reduzir o overhead, e resolver alguns dos problemas de quebra de frame-rates em jogos exigentes graficamente.
- O trabalho na implementação do Directx 10 e 11 andou um bocado parado
, o que motivou a mobilização por parte da Codeweavers (que lança as versões comerciais do Wine com adições proprietárias) para que a equipa do Wine trabalha-se internamente na implementação do DirectX 11. O Directx 10 já uns 75% implementado, mas falta funções da interface para ser activado. Espera-se que na versão 1.8 já seja possível correr jogos DX10 e DX11, pois prevê-se que o DX9 seja gradualmente abandonado no próximo ano. (A vinda das novas consolas baseadas no DX11 vão estimular o abandono no antigo DX9).- O Wine possui dois componentes autónomos: o Wine Internet Explorer (um wrapper MSHTML sobre o Gecko) e o Wine Mono (a implementação do .NET), que ainda não são suficientemente maduros para substituir a implementação nativa da Microsoft.
- Especula-se que uma terceira componente esteja na forja, que não é nada mais, nada menos que implementar o WinRT
, habilitando a execução de Aplicações Metro pelo Wine. (evidentemente que não será pela Windows Store...)Isto porque andaram a implementar as dll que surgiram com o Windows 8, e formam a base do WinRT (aparte do .NET que do qual é a linguagem padrão desta API)
- Também registaram correcções de bugs, completaram funções quebradas e deram continuidade a um projecto interno que estava ainda mais parado que o DX10 (que recomeçou ao cair do pano
): o suporte a controladores nativos do Windows para certos dispositivos USB.- Isto porque foi implementado no rc1 as primeiras funções relacionadas com o registo e instalação de controladores, que no Wine somente serão suportados controladores para dispositivos USB que operam no user-mode. (O Darling aparentemente suportará uma maior gama de controladores USB, visto que o IOKit é uma bibliotecas Unix-like e portanto mais fácil de sincronizar com o udev). Esta funcionalidade estará mais virada para dispositivos simples que são acompanhados com determinado software: como é o caso dos smartphones que utilizam software Windows para actualizar o seu firmware. (Não esperem que isso vá funcionar na versão 1.8!)
Em suma o lançamento do Wine 1.6 é mais uma versão de consolidação, mas com uma aposta clara para uma nova gama de dispositivos (os tablets Android e computadores ARM), e com o objectivo claro que preparar a versão oficial para o Mac OS X.
Tag351
Power Member
esse programa serve para alguma coisa? mais vale usar a virtualbox,ao menos funciona. a distro netrunner chegou a conclusao que nem vale a pena instalar na sua ultima versao de distro. gostei.Mantendo a tradição que foi a apresentação do Wine 1.4, eu anuncio que já foi lançado o primeiro release candidate do Wine 1.6 que representa o 3º estádio de desenvolvimento após o Wine alcançar a primeira versão estável.
Durante estes meses todos em que decorria as versões de desenvolvimento 1.5.x, no mundo Linux ocorrerem várias coisas, tais como:
- O lançamento de alguns jogos nativos para Linux.
- O lançamento do Darling (que já veio atrasado para o meu gosto
- Por fim, lançaram este mês o primeiro emulador Android decente para Linux que permite correr aplicações deste sistema operativo numa máquina Linux Desktop, útil para quem utilize aplicações como complemento. (AndroVM foi o protótipo, agora é o GenyMotion
Suspeito que a versão 1.6 seja a escolhida para criar uma versão oficial para Android, o problema é que como será escolhido e implementado o emulador x86 para os tablets (maioritários) ARM. Mesmo quando foi apresentado no FOSDEM o protótipo do Wine para Android, já existia na Google Play um emulador para correr alguns jogos (que são exactamente dois oficialmente suportados: Caeser III e Starcraft: Broody War 1.663) baseados no Windows em tablets Android: o programa Winulator.
O Winulator baseia parcialmente no source-code de uma porção do DirectX antigo (3 a 7) de acordo com o Wine, mais o trabalho do próprio autor em complementar algumas funções do WIN32 API. No entanto a grande diferença é este programa actua mais como um launcher sobre uma versão minimalista nativa em ARM do wrapper mini-DX7 para Open GL ES 2.0, acoplado com um emulador tipo binary translator/dynamic recompiler que faria a recompilação do executável do jogo (x86) num macro-código ARM na altura do lançamento da execução do jogo. Desta forma, o overhead entre arquitecturas foi minimizado e jogos que requerem pelo menos um Pentium MMX para terem um desempenho adequado podem ser executados num chip ARM dual e quad-core.
(Infelizmente o segredo daquela aplicação era mesmo o JIT x86/ARM, pelo que seria improvável que o autor cedesse o código-fonte para fundir com o Wine para Android, embora fosse o passo mais coerente, visto que o autor verificou que era impossível suster sozinho o desenvolvimento do Winulator sem fundi-lo com o Wine.
O Wine para Android irá resolver um problema fulcral do Winulator, visto que suportará as aplicações Desktop GDI e o DirectX, ao contrário do Winulator que requeria o rip da pasta do jogo do computador para o tablet, e só suportava o Direct3D em full-screen. Mas dificilmente o Wine superaria o módulo dos controlos que emulam parte das acções do rato que o Winulator possui (pois o seu objectivo era correr alguns jogos do Windows antigos, e não o Word!).
Embora o lançamento do Wine para Android será uma aplicação claramente disruptiva, o nosso interesse é destacar as novidades do Wine 1.6 que só serão aproveitadas devidamente em máquinas x86 baseadas em Linux ou Mac OS X. (A versão para Android não será provavelmente um port 1:1, pois dificilmente existem funções que nem a emulação x86/ARM daria remotamente qualquer rendimento palpável, salvo os tablets x86 com Android que vão surgindo recentemente).
O Wine 1.6 apresenta algumas novidades que são fulcrais (como a ênfase na versão Android que não é inocente de todo), dos quais destacamos:
- A arquitectura ARM é oficialmente suportada, embora na prática não tenha maior usuabilidade que servir de ferramenta de compilação de algum software Windows em máquinas Linux ARM. A versão para Android é derivada deste esforço. Para resolver fica a questão da emulação x86.
- O Wine para Mac OS X ganhou um driver nativo para o Cocoa API, substituindo a necessidade do X11.app para instalar e executar o Wine. Portanto as aplicações Windows no Mac OS X utilizam agora o Quartz API nativamente para o funcionamento deste emulador.
(Entretanto o suporte para X11.app ainda é mantido como opção caso ocorra problemas com o driver nativo.)
- O trabalho na emulação do Direct3D prosseguiu no último ano, destacando a implementação do próprio compilador de shaders e pipelines que pretende reduzir o overhead, e resolver alguns dos problemas de quebra de frame-rates em jogos exigentes graficamente.
- O trabalho na implementação do Directx 10 e 11 andou um bocado parado
- O Wine possui dois componentes autónomos: o Wine Internet Explorer (um wrapper MSHTML sobre o Gecko) e o Wine Mono (a implementação do .NET), que ainda não são suficientemente maduros para substituir a implementação nativa da Microsoft.
- Especula-se que uma terceira componente esteja na forja, que não é nada mais, nada menos que implementar o WinRT
Isto porque andaram a implementar as dll que surgiram com o Windows 8, e formam a base do WinRT (aparte do .NET que do qual é a linguagem padrão desta API)
- Também registaram correcções de bugs, completaram funções quebradas e deram continuidade a um projecto interno que estava ainda mais parado que o DX10 (que recomeçou ao cair do pano
- Isto porque foi implementado no rc1 as primeiras funções relacionadas com o registo e instalação de controladores, que no Wine somente serão suportados controladores para dispositivos USB que operam no user-mode. (O Darling aparentemente suportará uma maior gama de controladores USB, visto que o IOKit é uma bibliotecas Unix-like e portanto mais fácil de sincronizar com o udev). Esta funcionalidade estará mais virada para dispositivos simples que são acompanhados com determinado software: como é o caso dos smartphones que utilizam software Windows para actualizar o seu firmware. (Não esperem que isso vá funcionar na versão 1.8!)
Em suma o lançamento do Wine 1.6 é mais uma versão de consolidação, mas com uma aposta clara para uma nova gama de dispositivos (os tablets Android e computadores ARM), e com o objectivo claro que preparar a versão oficial para o Mac OS X.
PapiMigas
Power Member
Tag351, este "programa" não tem o mesmo principio do virtualbox. Corre aplicações diretamente "quase" como se fossem nativas, estilo office 2010 ou GTA, etc. Não sei se usas linux mas podes experimentar um programa chamado playonlinux que te mostra e instala as aplicações e jogos suportados, que são nativos de windows.
Comparar o Wine com virtualização completa como do Virtualbox não faz sentido.
O Wine não emula nada, permite correr os .exe e expõe ua implementação da API do Windows, pelo que vai dar ao mesmo que correr algo nativamente.
É possível correr jogos 3D em DirectX no Wine, e tendo performances aceitáveis (mas claro que casos são casos, uns correm perfeitamente, outros nem por isso), enquanto que com o Virtualbox pelo menos até recentemente não conseguias ter 3D por hardware dentro da VM, pelo que jogar era impossível. Agora é capaz de haver já algumas possibilidades nesta área mas continuas a ter o overhead de ter uma VM completa.
Curiosidade, o Virtualbox apenas suporta nativamente 3D por hardware em guests Windows com OpenGL. Para ter aceleração por hardware para DirectX é preciso incluir alguns .dll do Wine no guest Windows.
Portanto mesmo que consigas correr algum jogo DirectX no VirtualBox, vais ter as mesmas limitações que no Wine, e com pior performance ainda.
Como podes ver o Wine é um projecto bastante útil.
https://wiki.archlinux.org/index.php/VirtualBox_Extras#D3D_acceleration_in_Windows_guests
http://www.virtualbox.org/manual/ch04.html#guestadd-video
https://www.virtualbox.org/ticket/2940
Tag351
Power Member
sempre que se fala em wine,fala-se em jogos,se é esse o proposito,mas vale instalar Steam com jogos nativos a correr em linux.
Porquê que se fala em jogos? Porque é a área onde até agora as produtoras dos jogos mais populares não suportavam Linux e há uma grande procura pelos utilizadores de desktops, não havendo muitas alternativas ao mesmo nível, enquanto que noutro tipo de aplicações há quase sempre alternativas ao software do Windows tão boas ou melhores, mas mesmo assim com excepções, há quem prefira correr o Microsoft Office no Wine porque o prefere ao Libreoffice.
Agora começas a ter mais jogos polulares nativos em Linux, mas a Steam apenas te trouxe garantido os jogos da Valve. Se para ti qualquer jogo serve tudo bem, mas provavelmente outros pessoas vão querer jogar o último jogo da moda, ou um jogo clássico de há 15 anos atrás só para Windows.
O Wine torna possível executar coisas em Linux feitas exclusivamente para outro SO completamente diferente, algo que não era de todo um requesito, mas agrada a muita gente porque que mesmo não sendo perfeito, conseguir correr 20% ou 50% dos programas como se fosse nativamente é melhor do que não conseguir correr nada. Não percebo essa tua necessidade de mandar abaixo o Wine.
Arucard1983
Power Member
O Wine 1.6 foi oficialmente lançado no dia 18 de Julho e ja´ ganhou um fork especializado:
Para sistemas que utilizam os drivers Gallium 3D foi acrescentado o suporte nativo por hardware do Direct3D ao nivel de drivers, começando pelo DX9, pelo que foi lançado patches para que o Wine 1.6 tivesse acesso as API do DX9 implementadas pelo Gallium 3D, evitando o overhead da conversao DX/GL.
O autor do fork espera que o suporte do Gallium 3D para o Direct 3D 10 e 11 seja refeito de forma consistente entre o Wine 1.7.x e o driver Gallium 3D obtendo uma performance nativa nos jogos que corram no Wine.
Para sistemas que utilizam os drivers Gallium 3D foi acrescentado o suporte nativo por hardware do Direct3D ao nivel de drivers, começando pelo DX9, pelo que foi lançado patches para que o Wine 1.6 tivesse acesso as API do DX9 implementadas pelo Gallium 3D, evitando o overhead da conversao DX/GL.
O autor do fork espera que o suporte do Gallium 3D para o Direct 3D 10 e 11 seja refeito de forma consistente entre o Wine 1.7.x e o driver Gallium 3D obtendo uma performance nativa nos jogos que corram no Wine.