mboost-dp1

Electronic Arts

EA’s spil til Mac er Windows versioner

- Via Transgaming - , redigeret af Derfor

Efter at Electronic Arts netop har annonceret at de til juli og august vil figive en række af deres titler til Mac OS X, så har firmaet Transgaming frigivet en pressemeddelelse, som afslører hvordan EA har fået spillene til at køre under OS X.

Transgaming er udvikleren af den såkaldte “Cider Engine” som er en wrapper ligesom wine er til Linux, Cider Engine gør det muligt at afvikle Windows spil på et andet operativsystem.

Der er altså ikke tale om omskrivning af spillene så de virker direkte under OS X, men en emulering. Det kan betyde ydelsestab og at spillene kun vil virke med Intel baserede Macs.





Gå til bund
Gravatar #51 - trylleklovn
13. jun. 2007 21:11
#50 Hvorfor er du på newz når du drikker rødvin og ikke er hjemme .. ..
Gravatar #52 - fidomuh
13. jun. 2007 21:12
#51

Er lige kommet retur til hotellet efter superb mad i Svendborg :)

Saa drikker ikke roedvin lige pt, har bare drukket en del :P
Gravatar #53 - dub
13. jun. 2007 21:22
Men hvem af jer ramme rigtigt? virker det eller virker det ikke.
Jeg har ikke nogen programmer hvor jeg kan kan crashe OS X i fullscreen, aka jeg bruger ikke fullscreen programmer.
Gravatar #54 - fidomuh
13. jun. 2007 21:25
#53

Ah, du spiller vel WC3 i fullscreen i ny og nae?! :D

Arj, det virker oftest.. Konklusionen er vel bare at man skal have en maade at skifte aktivt program..
Fx alt-tab..
Gravatar #55 - kasperd
13. jun. 2007 21:27
Jeg håber da at det her bare er det første skridt i en retning mod bedre portabilitet. Windows API har længe haft det problem, at den skrevne specifikation aldrig er blevet betragtet som autoritativ. Derimod er det altid den seneste implementation fra Microsoft, der blev betragtet som autoritativ.

Hvis en applikation ikke virkede korrekt på Windows blev det betragtet som en fejl i applikationen. Hvis en applikation ikke virkede på Wine blev det betragtet som en fejl i Wine. Og det var uanset, hvad specifikationen så end måtte sige om, hvad der var korrekt.

Hvis Microsoft laver en ny version af Windows som fik nogle applikationer til at holde op med at virke, så var det fejl i applikationerne, som gjorde noget, de aldrig burde have gjort. Men havde det været en ny version af Wine, som ikke kunne køre applikationerne. Så ville det selvfølgelig være en fejl i Wine.

Vi må håbe, at efterhånden som der kommer flere implementationer af APIen, så vil der være færre som begår den fejl at betragte en som autoritativ, og flere som tester deres kode mod forskellige implementationer og retter de fejl, de finder. Indtil videre har vi Wine, Transgaming, Reactos, XP, Vista. De nævnte spil burde have en bedre chance for at virke godt under Wine end andre spil.

[url=#5]#5[/url] tgr
Der er næsten ikke noget værre, det skulle dog lige være brugere af IP!
Version 4 eller version 6?

[url=#12]#12[/url] Jokse
og kører Windows mv. med modifikationer (Bootcamp).
Jeg troede bootcamp var et stykke software.

[url=#24]#24[/url] trylleklovn
Jeg har ikke købt en Mac for at spille spil på den, så nyheden er ret ubetydelig for mig.
Hvis det her er starten på en tendens der går i retning af mere portable programmer, så kunne det da sagtens gå hen at få betydning for dig når effekten på et tidspunkt breder sig til andet end spil.

[url=#32]#32[/url] mathiass
Det giver ikke mening at lave hastighedssammenligninger mellem er fuld implementation og en halv.
Hvis der er applikationer, som kan bruges i den begrænsede implementation giver det da i høj grad mening. At applikationen kører langsommere i en fuld implementation end i en begrænse implementation kan der selvfølgelig være forskellige forklaringer på. Det kan være applikationen er tåbeligt designet, eller det kan være at den fulde implementation bare ikke er en særligt effektiv implementation.

Der er tale om en wrapper som oversætter kald til Windows funktioner til noget OS X kan vise.
Wrapper er selvfølgelig en mere korrekt beskrivelse end en emulation. Men det er nu ikke åbenlyst om wrapper eller reimplementation er den mest præcise beskrivelse.

Ville du kalde glibc for en wrapper omkring Linux? (jeg vælger det eksempel fordi, det er det, jeg kender bedst). Der er ikke ret mange programmer på Linux som kalder Linux direkte, de går næsten alle gennem glibc. Linux uden glibc (eller tilsvarende) er ikke et posix system, det lever faktisk ikke engang op til ansi C.

Der er ingen som vil påstå, at fordi Linux er implementeret på den måde, så er det ikke en implementation af posix. Faktisk tror jeg at hovedparten af de tilgængelige posix implementationer er implementeret på samme måde, med en kerne og et C library ovenpå (nogle har endnu flere lag). De to lag er bare en fornuftig måde at implementere det på, hvis funktionalitet kan flyttes ud af kernen og over i et library giver det ofte et mere stabilt system. (Og hvis det gøres rigtigt går det ikke ud over performance).

Windows er mig bekendt implementeret på en tilsvarende måde med et library som står for at at kalde de egentlige systemkald. Det vil sige, at uanset hvilket af disse systemer du ser på, så har du et interface under det basale library og et andet interface ovenpå.

Man kan så lave et library, der anvender det ene eller det andet interface under librariet og det ene eller det andet interface over librariet. Uanset hvilken af de fire kombinationer du vælger bliver der ikke tale om mere eller mindre wrapper.

Så med mindre en implementation tilføjer et ekstra lag i stakken, som burde have været overflødligt, så vil jeg ikke kalde det for en wrapper. Og under alle omstændigheder er der tale om en implementation - ikke af en windows kerne, men af den API du opnår med en windows kerne og tilhørende libraries.

At EA selv laver denne konfiguration og supporter det officielt er et kæmpe skridt frem og giver muligheden for noget bedre i fremtiden.
Enig. Og det burde samtidigt eliminere noget af behovet for grimme hacks. En lille bug i en applikation, som tilfældigvis virker i Windows, kan resultere i et behov for et grimt hack for at få samme applikation til at virke i Wine (eller for den sags skyld senere versioner af Windows). Men hvis det er udvikleren af applikationen, som render ind i den, så vil en langt nemmere og langt bedre løsning være, at rette fejlen.

[url=#33]#33[/url] mathiass
Det store problem med den teknik er at man ikke kan prale til sine venner med sin uptime.
Nu har Mac OS X aldrig givet mig uptimes jeg ville prale af. Min oplevelse er at efterhånden som systemet får lov at køre i lang tid er der bare ting, der holder op med at virke. Og på et eller andet tidspunkt bliver man nødt til at reboote (om ikke før, så når maskinen ikke kan vågne fra suspend). Senest oplevede jeg at først holdt PPP over bluetooth op med at virke, nogle dage senere holdt wifi op med at virke. Og når man er nået dertil, så er det altså så irriterende, at man bare rebooter for at få ting til at virke igen.
Gravatar #56 - el_senator
13. jun. 2007 21:43
Hvorfor er det at folk sidder og skriver Wine hele tiden? Cedega's teknologi har meget lidt tilfælles med Wine i dag, så lad være med at kalde det Wine, når det ikke er det.

Transgaming startede i sin tid med at lave en fork af Wine, kaldet WineX. Idéen var at det skulle være Wine med et DirectX kompatibilitetslag. Så blev de grådige og begyndte at tage penge for skidtet, og i dag er Cedega og Wine næsten helt skilt fra hinanden.

Wine har i dag sit eget DirectX kompatibilitetslag, der er under hastig udvikling.
Gravatar #57 - dub
13. jun. 2007 22:03
#55
Nu har Mac OS X aldrig givet mig uptimes jeg ville prale af. Min oplevelse er at efterhånden som systemet får lov at køre i lang tid er der bare ting, der holder op med at virke. Og på et eller andet tidspunkt bliver man nødt til at reboote (om ikke før, så når maskinen ikke kan vågne fra suspend). Senest oplevede jeg at først holdt PPP over bluetooth op med at virke, nogle dage senere holdt wifi op med at virke. Og når man er nået dertil, så er det altså så irriterende, at man bare rebooter for at få ting til at virke igen.
Hvorfor har du brug for at reboote? Jeg har en uptime på 13 dage(uden at det er godt og det er OS X) men hvis min Windows maskine ikke larmende så meget så kunne den nemt have samme uptime.
Både OS X og Windows (og whatever BSD/Linux) er i stand til at holde en maskine kørende i lang tid, så hvorfor tæller uptime ?
Gravatar #58 - bjerh
13. jun. 2007 22:46
#45.. Har ikke set RSOD eller GSOD.. Men BSOD er lige så klam og kedelig som altid. :)
Gravatar #59 - dub
13. jun. 2007 23:26
#58 Så Vista har flere farve? Jeg har ikke prøvet Vista men NT kernen har ikke haft så mange problemmer med at dø. Men alle *SOD er kedelig (er OS X T(som i Transparent)SOD.
Gravatar #60 - TWFH
14. jun. 2007 05:29
#58, 59: Man kan ændre farven i system.ini under [386enh]. Tilføj følgende entries:
MessageBackColor=[x]
MessageTextColor=[y]
hvor [x] og [y] hver især er en af flg. farver:

0 = black
1 = blue
2 = green
3 = cyan
4 = red
5 = magenta
6 = yellow/brown
7 = white
8 = gray
9 = bright blue
A = bright green
B = bright cyan
C = bright red
D = bright magenta
E = bright yellow
F = bright white

Jeg anbefaler brun baggrund med skarp grøn tekst, det ser bare knaldgodt ud når XP crasher (7-9-13).
Gravatar #61 - T-10.000
14. jun. 2007 06:53
[url=http:http://www.winehq.org/site/myths]wine er ikke en emulator[/url] "Transgaming er udvikleren af den såkaldte "Cider Engine" som er en wrapper ligesom wine er til Linux, Cider Engine gør det muligt at afvikle Windows spil på et andet operativsystem.

Der er altså ikke tale om omskrivning af spillene så de virker direkte under OS X, men en emulering. Det kan betyde ydelsestab og at spillene kun vil virke med Intel baserede Macs."


så hvorfor skifter du fra wrapper til emulator midt i det hele, det gik ellers lige så godt.
Gravatar #62 - T-10.000
14. jun. 2007 08:07
og det var så dette"wine er ikke en emulator" jeg prøvede at linke til før.
Gravatar #63 - kasperd
14. jun. 2007 20:03
[url=#56]#56[/url] el_senator
Cedega's teknologi har meget lidt tilfælles med Wine i dag, så lad være med at kalde det Wine, når det ikke er det.
Mon ikke de stadig har noget kode til fælles. Men hvis de har udviklet sig så langt fra hinanden, at det må betrages som to implementationer, så er det også godt nok. Begge står stadig over for de samme problem, nemlig at for mange udviklere tror, der kun findes en implementation af APIen. Og det kan flere forskellige implementationer vel kun hjælpe med til at løse. Så jeg tror at de har glæde af hinandens eksistens.

[url=#57]#57[/url] dub
Hvorfor har du brug for at reboote?
Fordi det er nu engang så upraktisk med en netforbindelse, der ikke virker. Men hvis du har en løsning på alle de problemer som langsomt dukker op i en Mac OS X, der ikke bliver rebootet, så lytter jeg gerne.

Jeg har en uptime på 13 dage(uden at det er godt og det er OS X) men hvis min Windows maskine ikke larmende så meget så kunne den nemt have samme uptime.
Jeg rebooter nu sjældent Mac OS X så ofte. Sidst gik der over en måned. Men når jeg nu tænker på, at jeg til tider har haft Linux kørende i et halvt år, og da jeg endeligt rebootede var det blot for at opgradere kernen.

Både OS X og Windows (og whatever BSD/Linux) er i stand til at holde en maskine kørende i lang tid, så hvorfor tæller uptime ?
I mit sidste job var det nødvendigt at bruge Windows. Jeg tror aldrig min maskine der nåede at have en oppetid på mere end 14 dage. Men i al den tid jeg arbejdede der blev min private Linux server ikke rebootet én eneste gang.

Og med Mac OS X er der altid opstået et problem som gjorde det nødendigt at reboote efter højst en måneds tid.
Gravatar #64 - mathiass
14. jun. 2007 20:14
I mit sidste job var det nødvendigt at bruge Windows. Jeg tror aldrig min maskine der nåede at have en oppetid på mere end 14 dage.
Hmm, jeg bruger en helt almindelig Windows XP på arbejdet og jeg genstarter kun eller for den sags skyld logger ud når der er patches som skal installeres omkring den første tirsdag i måneden. Det giver ikke mig nogen problemer.

Og med Mac OS X er der altid opstået et problem som gjorde det nødendigt at reboote efter højst en måneds tid.
Ja, så lang tid plejer jeg ikke at kunne holde den. Spotlight har det blandt andet med at crashe (viser ingenting) og så hjælper kun en genstart.

Men en genstart er ikke det værste. Den giver én en unik mulighed for lige at skifte underhylerne og få et hurtigt truckerbad...
Gravatar #65 - fidomuh
14. jun. 2007 20:37
#63

Mjah, min server har ca en uptime paa ~60 dage foer den rebootes / crasher / something, saa 30 dage er helt fint for en workstation..

Min imac har pt en uptime paa ~2 timer ( har lige installeret random updates ), men foer det snakker vi reelt >35 dage..
Den bliver sat i sleep hver morgen og brugt heftigt hver aften..

Det er rigeligt til mig..
Specielt naar jeg kigger paa min Vista laptop..
Den er mildest talt lidt "cracky" efterhaanden.. Og den bliver endda slukket hver dag :P

Ja, så lang tid plejer jeg ikke at kunne holde den. Spotlight har det blandt andet med at crashe (viser ingenting) og så hjælper kun en genstart.


Hmm.. Jeg bruger ikke spotlight nok saa :D

Har endnu ikke oplevet spotlight crashe.. Det vaerste jeg har set var at den ikke returnede noget, hvor jeg klikkede udenfor vinduet og saa proevede spotlight igen = instant work :)
( Og det er sket 1 gang ca :D )

Men en genstart er ikke det værste. Den giver én en unik mulighed for lige at skifte underhylerne og få et hurtigt truckerbad...


Praecis :)

Det er foerst slemt naar maskinen begynder at koere daarligt selvom den bliver "refreshet" engang imellem ;)
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login