Snart kan du få heftig spillgrafikk i nettleseren

[Cuneax]

Ny demonstrasjon viser Unreal Engine 3 i HTML5.

Snart kan du få heftig spillgrafikk i nettleseren

[Hayer]

Blir litt lei meg av at det skal satses så mye på grafikk i nettleseren, men, men - dette så jo ikke så altfor ille ut.

[Fnix]

Unreal Tournament i nettleseren? Ja takk!

På tide at de tar igjen Quake Live som har vært ute mange år i nettleseren.

[Neppe]

Blir litt lei meg av at det skal satses så mye på grafikk i nettleseren, men, men - dette så jo ikke så altfor ille ut.

Tenk deg hvor mange muligheter det åpner. Du kan spille AAA spill i nettleseren din, og det uten noen stor nedlasting.

 

Også kan man pensjonere Flash, som lenge har vært ganske ut datert.

[Merko]

Tenk deg hvor mange muligheter det åpner. Du kan spille AAA spill i nettleseren din, og det uten noen stor nedlasting.

 

Også kan man pensjonere Flash, som lenge har vært ganske ut datert.

Man må jo laste ned alle modellene, texturene osv?

 

Aner ikke hvor mye som ble lastet ned i Epic Citadel demoen, men var over 50mb iallefall ;p

[zomfg1]

Blir litt lei meg av at det skal satses så mye på grafikk i nettleseren, men, men - dette så jo ikke så altfor ille ut.

Tenk deg hvor mange muligheter det åpner. Du kan spille AAA spill i nettleseren din, og det uten noen stor nedlasting.Også kan man pensjonere Flash, som lenge har vært ganske ut datert.

 

Har vel sine fordeler, men selv foretrekker jeg å ha hele spillet installert. Skulle nettet ryke, vil jeg ikke merke det, men kunne spille videre.

[Neppe]

Har vel sine fordeler, men selv foretrekker jeg å ha hele spillet installert. Skulle nettet ryke, vil jeg ikke merke det, men kunne spille videre.

De fleste nyere spill krever nettilkobling uansett. Se for deg onlinespill, her er dette en kjempefordel

[TheGaame]

Blir litt lei meg av at det skal satses så mye på grafikk i nettleseren, men, men - dette så jo ikke så altfor ille ut.

Tenk deg hvor mange muligheter det åpner. Du kan spille AAA spill i nettleseren din, og det uten noen stor nedlasting.Også kan man pensjonere Flash, som lenge har vært ganske ut datert.

Har vel sine fordeler, men selv foretrekker jeg å ha hele spillet installert. Skulle nettet ryke, vil jeg ikke merke det, men kunne spille videre.

 

blir et smått problem om du spiller multiplayer...og nette tar kvelden...

 

[zomfg1]

De fleste nyere spill krever nettilkobling uansett. Se for deg onlinespill, her er dette en kjempefordel

 

Jeg er så å si alltid koblet til nettet, og kjører altfor mange spill igjennom Steam, men er prinsippsak, liker ikke "always-online" DRM, og dette blir veldig som det.

 

Men multiplayer spill kan det være en ide med ja. Så lenge det funker bra med alle knapper på tastaturet, og ikke feks windowsknappen går til start-meny så nettleser ikke lengre er aktivt vindu. Det kan fikses med nyere tastaturer tho, og er vel generellt ett problem i vanlige spill også.

[Skinney]

Blir litt lei meg av at det skal satses så mye på grafikk i nettleseren, men, men - dette så jo ikke så altfor ille ut.

Tenk deg hvor mange muligheter det åpner. Du kan spille AAA spill i nettleseren din, og det uten noen stor nedlasting.Også kan man pensjonere Flash, som lenge har vært ganske ut datert.

Har vel sine fordeler, men selv foretrekker jeg å ha hele spillet installert. Skulle nettet ryke, vil jeg ikke merke det, men kunne spille videre.

 

HTML5 har også offline API, som gjør at nettsider kan aksesseres offline, og heller oppdateres når nettverk er tilgjengelig. Så lenge de som lager spillet i nettleseren vet hva de driver med, så skal ikke dette være ett problem.

 

@Merko: Hvis utviklerne gjør jobben skikkelig, så kan første brett lastes ned først, og mens du spiller kan resten av spillet lastes ned, eller ikke...

 

Største fordelen med spill i nettleseren er uansett at det er veldig lett å synkronisere save-games, og at så og si alle enheter per idag har en nettleser, slik at du kan spille mer eller mindre overalt.

[Gjest Slettet-x7D6du0Hjb]

Jeg kan ikke fordra spil i nettleseren (utenom litt Runescape). Har prøvd Warface (BETA) og så langt er jeg ikke imponert.

[Skinney]

Snart kan du få heftig spillgrafikk i nettleseren

 

Liten feil i artikkelen. Emscripten støtter ikke C++, den støtter LLVM IR, som vil si at alle språk som kan kompileres med LLVM i utgangspunktet kan gjøres om til javascript (med asm.js som en valgmulighet). De mest populære språkene å bruke med Emscripten er C og C++, men D og Rust skal også være en mulighet. Ytelsen av emscripten + asm.js kompilert kode skal klare å komme innenfor halvparten av hva du får til med C/C++. Til sammenligning klarer eksempelvis Java og C# gjerne en tredjedel, så det er ganske stort.

 

Jeg kan ikke fordra spil i nettleseren (utenom litt Runescape). Har prøvd Warface (BETA) og så langt er jeg ikke imponert.

 

Tja. Nå er det fullt mulig for HTML5 apps å kjøre fullscreen og støtte gamepad. Da vil du nok ikke merke forskjell på om du kjører i en browser eller native app. At dagens HTML5 spill er dårlig implementert er nok fordi det er såpass nytt, men ser for meg at det kan forandres ganske fort.

[tabbeber]

RuneScape eksperimenterer med HTML akkurat no. (I lukka beta)

Ser mykje betre ut en Java, men det er RS, så grafikken er ikkje ein gong i nærleiken av dette.

Spel er nok uansett best i klient, sjølv om HTML ser ut til å takle det ganske bra.

[havarhen]

Testet den i Firefox Nightly 23, funket bra :-) Jevn bevegelse.

Prøvden den i Chrome 26, men der kræsjet tab-en. (Edit: testet også Chrome canary 28, men den kræsjet der også).

(Internet Exploder støtter ikke WebGL, men de kommer sikkert sent til leken som vanlig).

Endret 6. mai 2013 av havarhen

[Blazer]

Blir litt lei meg av at det skal satses så mye på grafikk i nettleseren, men, men - dette så jo ikke så altfor ille ut.

Tenk deg hvor mange muligheter det åpner. Du kan spille AAA spill i nettleseren din, og det uten noen stor nedlasting.Også kan man pensjonere Flash, som lenge har vært ganske ut datert.

Har vel sine fordeler, men selv foretrekker jeg å ha hele spillet installert. Skulle nettet ryke, vil jeg ikke merke det, men kunne spille videre.

blir et smått problem om du spiller multiplayer...og nette tar kvelden...

 

ikke alle er MP horer

[efikkan]

Snart kan du få heftig spillgrafikk i nettleseren

Ingen ved sine fulle fem vil kalle dette heftig grafikk i dag, for ti år siden hadde det vært noe annet.

 

Spill i HTML5 og JavaScript vil erstatte Flash og JRE, men ikke spill hvor ytelse eller respons er viktig. Først kommer nok tullespill som Farmwille, men etterhvert enkle rollespill(gjerne mmorpg) og enkle strategispill. For spill som krever respons og presisjon er derimot threading og IO-kontroll svært viktig.

 

Båndbredde vil også bli et seriøst problem, så gratisspill og reklamefinansierte spill vil ha svært lave båndbreddekrav siden dette er noe som koster veldig mye.

 

Min største bekymring er at Javascript er allerede den største trøblemakeren i nettlesere (utenom plugins som JRE og Flash), og er den største årsaken til sikkerhetsproblemer. Med nettlesernes stadige nye versjoner er det allerede et mareritt å sørge for feilfri Javascript-kode.

[Skinney]

Ingen ved sine fulle fem vil kalle dette heftig grafikk i dag, for ti år siden hadde det vært noe annet.

 

Kontekst er viktig. Mtp at alt dette kjøres i ett dynamisk språk som javascript (ofte 5-6x tregere enn C/C++) så er dette temmelig heftig.

 

Spill i HTML5 og JavaScript vil erstatte Flash og JRE, men ikke spill hvor ytelse eller respons er viktig. Først kommer nok tullespill som Farmwille, men etterhvert enkle rollespill(gjerne mmorpg) og enkle strategispill. For spill som krever respons og presisjon er derimot threading og IO-kontroll svært viktig.

 

Tror nok alle spill som ikke krever super-rask responstid (FPS mao.) klarer seg fint. Jeg kjørte Citadel demoen med 22 frames per second på ett Intel HD3000 skjermkort, så tror ikke det hadde vært noe problem å kjøre eksempelvis Dragon Age: Origins over nettleseren med denne teknologien. MMORPGer derimot tror jeg hadde blitt ett problem, da nettlesere ikke støtter UDP og WebSocket protokollen ikke er like rask som ren TCP.

 

Båndbredde vil også bli et seriøst problem, så gratisspill og reklamefinansierte spill vil ha svært lave båndbreddekrav siden dette er noe som koster veldig mye.

 

Hvorfor skulle båndbredde bli ett stort problem? Når du først har lastet ned resursene du trenger blir de liggende på harddisk til du sletter nettleser-cachen. Det er også fullt mulig å kun laste ned de ressursene du trenger utifra hvor du er i spillet. Spill som lages på denne måten trenger derfor ikke bruke noe mer båndbredde enn f.eks. Steam.

 

Båndbredde er heller ikke spesielt dyrt.

 

Min største bekymring er at Javascript er allerede den største trøblemakeren i nettlesere (utenom plugins som JRE og Flash), og er den største årsaken til sikkerhetsproblemer. Med nettlesernes stadige nye versjoner er det allerede et mareritt å sørge for feilfri Javascript-kode.

 

tre ting.

 

Det er ikke noe som heter feilfri kode, uansett språk, punktum.

 

Problemet med javascript og nettlesere er at hver nettleser har sin egen implementasjon av javascript (og HTML og CSS), noe som betyr at på visse områder fungerer samme kodesnutt annerledes utifra hvilken nettleser du er i. Heldigvis har de forskjellige nettleserne faktisk begynt å følge standarden ordentlig, så i nyere nettlesere er det mer, ikke mindre, sannsynlig at javascript fungerer likt uavhengig av nettleser.

 

Sist, men ikke minst, javascript (og flash, og Java) er langt mer sikkert enn språkene som vanligvis brukes for å lage spill (C, C++). Javascript er heller ingen trøbbelmaker, eller en stor årsak til sikkerhetsproblemer. Det som derimot er tilfellet er at folk flest ikke liker javascript fordi det er ett... uelegant... språk, og at folk er kreative til å bruke javascript til å lure systemet. Mtp hvor lukket miljø(sandboks) javascript kjører i, er nok javascript vesentlig mer sikkert enn eksempelvis Java (android apps) og Objective-C(iOS apps).

[omnomnomnivore]

Ser jo fint ut dette og jeg kan se bruksområder for det, men ikke for AAA spill. For da bytter man jo et lite problem mot et stort et.

[Liquicity]

Man spiller ikke i en nettleser... Man spiller "fullscreen" i borderless window, alltid. Grunnene for å kunne spille i nettleseren er forsvunnet og de nødvendige forutsetningene var aldri tilstede samtidig, i alle fall ikke nå.

[efikkan]

Hvorfor skulle båndbredde bli ett stort problem? Når du først har lastet ned resursene du trenger blir de liggende på harddisk til du sletter nettleser-cachen. Det er også fullt mulig å kun laste ned de ressursene du trenger utifra hvor du er i spillet. Spill som lages på denne måten trenger derfor ikke bruke noe mer båndbredde enn f.eks. Steam.

Båndbredde er heller ikke spesielt dyrt.

Du bør nok regne på det der. Hvis du skal distribuere et spill som tar f.eks. beskjedne 100 MB (som er lite innhold) til 10.000 kunder i løpet av én måned, vil du trenge 1 TB med båndbredde som er langt mer enn noen shared host vil gi deg i praksis. I tillegg må du huske at nedlastingene ikke kommer jevnt, så distribusjonssystemet må dimensjoneres for dette. Da står du igjen med valget mellom en serverinfrastruktur eller CDN, hver med sine fordeler. Uansett så koster dette for penger, og denne kostnaden må veies opp mot fortjenesten du får per kunde. Hvis spillet er reklamefinansiert så må du regne med uner 1 kr i fortjeneste per kunde i et tidsintervall, og båndbredden må dimensjoneres deretter. Hvis du derimot selger tjenester eller abonnement for f.eks. 100 kr så kan du levere langt mer båndbredde og dermed innhold og fremdeles ha god fortjeneste.

Det er ikke noe som heter feilfri kode, uansett språk, punktum.

Dette er en vanlig misforståelse.

Kode i seg selv kan være 100% feilfri. Hvis en programmerer har full oversikt over hvordan koden går fra f.eks. C til maskinkode, og derfra til mikrokode (noe er AMD- og Intel-spesifikt), og kontrollerer at ingen feil kan intreffe så er koden 100% feilfri. Dette er svært omfattende men gjennomførbart. For høyere nivås språk er det derimot en tilnærmet uoverkommelig oppgave. Den eneste typen feil som kan inntreffe hvis koden er feilfri er feil som oppstår i selve elektronikken. Noen catching av exceptions kan aldri fange denne typen feil uansett, men tiltak som ECC i minnet kan redusere risikoen noe.

Problemet med javascript og nettlesere er at hver nettleser har sin egen implementasjon av javascript (og HTML og CSS), noe som betyr at på visse områder fungerer samme kodesnutt annerledes utifra hvilken nettleser du er i. Heldigvis har de forskjellige nettleserne faktisk begynt å følge standarden ordentlig, så i nyere nettlesere er det mer, ikke mindre, sannsynlig at javascript fungerer likt uavhengig av nettleser.

Med bare små forskjeller i javascript-implementasjoner så vil det bli forskjeller i koden som kjører i CPUen.

For å reduserer problemene med javascript bør det nok lages en enorm pakke med "unit testing", som sjekker omtrent alt tenkelig og tenkelig i spesifikasjonen. En litt lite spesifikk standard er ikke tilstrekkelig, ei heller en streng standard hvis det ikke verifiseres at denne følges til punkt og prikke.

Sist, men ikke minst, javascript (og flash, og Java) er langt mer sikkert enn språkene som vanligvis brukes for å lage spill (C, C++).

Dette er en utbredt misforståelse. For det første er det ikke snakk om sikkerhet som i security, det refereres til "safety" som er tenkt å hindre utvikleren i å gjøre "dumme ting" som bryter med programmeringsparadigme. Det er altså lagt inn noen sperrer som skal hindre bestemte ting som i følge paradigmet ikke er en god idé, siden det muligens kan føre til ustabilitet. Dette forutsetter at programmereren har forstått paradigmet (hva det er og ikke er), men er i praksis ingen garanti for korrekt objektorientering eller håndtering av feil. Sammen med slike språk er det også en rekke patterns som typisk brukes, f.eks. MVC, hvor implementasjonen er svært kritisk for at det skal fungere. Språket bidrar ingenting her, og i tillegg har f.eks. MVC mange synkroniseringsproblemer som jeg ikke skal gå inn på her. Hovedargumentet for disse språkene er gjerne å unngå bryderiet med eksplisitte pekere og minneallokering, og erstatter dette med automatikk og "søppelinnsamling", som er kjent for både minnelekkasjer og for tidlig frigjøring av minne.

 

Det forbauser meg stadig hvordan både nyutdannede programmerere og mangeårige utviklere kan komme med utsagn som "det er sikkert fordi vi bruker Java", "vi bytter ut C med Java for å gjøre det sikkert" eller at "sikkerheten er i språket(Java, C#, Ada osv.)", og du er sikkert enig i at dette bunner i en fundamental misforståelse. Jeg har lyst til å trekke frem et lite eksempel fra en arbeidsplass hvor de leverer tjenester til en rekke bruksområder. Mange av produktene bruker Ada fordi kundene krever det av "sikkerhetsmessige årsaker". Dette er et språk som er basert på Pascal, men som har byttet ut ObjectPascals elegante objektsyntaks med noe som minner mer om måten prosedyrer bruker structs i C, selv om det er objektorientert funksjonalitet. Ada har i tillegg tasks som skal utføres synkront osv, som er den store safety-featuren som brukes for Ada i kritiske komponenter (embedded, infrastruktur, militært osv). Ada er som kjent mye strengere enn f.eks. Java i forsøk på å hindre utvikleren i å gjøre dumme ting, så strengt at de fleste som jobbet med Ada som jeg møtte på hatet språket. I et prosjekt skulle jeg finne ut hvorfor noe kode oppførte seg rart i noen få tilfeller fant jeg ut at noen runtimes var erstattet med noe egenutviklet i bedriften. Noe kode var fra etter 2000, men noe var også fra tidlig 90-tall. Blant annet var det synkroniserings-biten av språket som var byttet ut, og trøblemakeren for prosjektet jeg jobbet med var en helt defekt implementasjon av mutex. For det første gikk alltid mutexen i lås, som gjør at programmet skulle henge, men i tillegg var sjekkemekanismen defekt (pga. en feil negering), så den andre feilen oppveide den første, og den totale effekten var ingen synkronisering. Dette biblioteket var brukt på tvers av Ada-prosjektene. Slikt skjer når utviklere ikke forstår hva de driver med.

Javascript er heller ingen trøbbelmaker, eller en stor årsak til sikkerhetsproblemer.

For Firefox og Safari har de fleste alvorlige feil vært tilknyttet javascript, og javascript er ikke en ukjent trøblemaker for IE, Opera eller Chrome heller.