AJAX MMORPG - IE te langzaam, FF knippert

[Verwijderd]

Na een succesvolle eerste post hoopte ik antwoord te vinden op een probleem waar ik al geruime tijd mee bezig ben. Ik ben bezig met een grafische Massive Multiplayer Online Roleplaying Game te maken geheel in JavaScript, PHP, (D)XHMTL en AJAX. Alles verloopt goed op één probleem na.. Dit vormt de bottleneck van mijn hele project!

Visueel, heb ik me ingehouden tot een karakter die van tile naar tile 'verspringt'. Een raster van Div-blocks. Je karakter is een img die bij elke verplaatsing een nieuwe tile krijgt waar het plaatje in moet laden, alle andere tiles worden geleegd natuurlijk.. anders trek je een spoor van jezelf achter je aan.

het verplaatsen gaat over twee ajax objecten:

keymovement (input):
- keypress: kijken welke toets is aangeslagen
- op basis daarvan nieuwe locatie uitrekenen voor jouw karakter
- is er sprake van blokkades, teleports of een nieuwe map? (buiten beeld lopen) --> andere functies
- zo nee: nieuwe locatie opslaan in db

maprefresh (output):
- db request --> locatie spelers + naam (+richting die je opkijkt)
- inhoud van alle velden = "" (legen)
- image_naamvanspeler_kijkrichting.gif komt in tile id="locatie speler"
- herhaal elke 350ms (zonder einde)

Ik heb dit dus uitgewerkt en het werkt.. je kunt heen en weer lopen, tussen mappen lopen, je kunt tegen objecten oplopen waar je niet verder kunt etc. etc. Ik draai nu alles op localhost. Maar heb ook al geprobeerd op een public. (thuiscomputer als server, school als client, vrienden als client)
Het is probleem is dit:

Internet Explorer:
in het begin lijkt het redelijk soepel te gaan.. maar de mousepointer verandert na elke refresh even snel in een zandloper!! Ik dacht dat het over was met de zandlopers in ajax.. appearently not.
Bovendien wordt mijn poppetje iedere keer trager. Mijn lichtbruine vermoeden is dat dit iets te maken heeft met cacheproblemen. Ik heb al eerder problemen gehad, die alleen internetexplorer had en firefox niet. IE wil het cache gebruiken en zo bleef mijn poppetje op de locatie staan, die IE in zijn cache ziet. Opgelost met php headers, ergens uit een forum gerukt.

Firefox:
Firefox handelt de boel redelijk netjes af. Op school zelfs precies zoals ik het wil. Het poppetje reageert direct, hoeft niet na te denken, de pointer blijft zoals ik die heb ingesteld in css.. Alleen thuis (en op andere geteste machines) flikkeren de poppetjes.. datgeen wat iedere keer opnieuw er in wordt gezet met innerHTML, flikkert..Geldt ook voor het chatscherm. Dit ervaar ik als irritant. Is hier een workaround voor of, ben ik dom bezig met innerHTML? Moet ik firefox bewust laten cachen oid?

Graag jullie kennis als dit probleem bekend voorkomt, of als je er een filosofie over hebt! Als je code fragmenten wilt, zal ik direct reageren.

[Janoz]

Ik denk dat je idd dom bezig bent met innerHTML ..

Waarschijnlijk kun je je personage beter absoluut positioneren. Je hoeft dan immers alleen de top en de left aan te passen. Je hoeft dan niet meer een compleet nieuw plaatje te laden en je vorige tile te vervangen. Bijkomend voordeel is dat je de verplaatsing kunt animeren door in een loopje je plaatje te verplaatsen.

[Not Pingu]

Je schrijft dus bij iedere stap in de database? Het lijkt me dat er betere manieren zijn om je gamestate te persisten in dit geval (gewoon een in-memory object aan serverzijde).

Ik kan zo niet precies ruiken hoe je het e.e.a. geimplementeerd hebt, maar wacht je presentatielaag tot de server klaar is met het wegschrijven van elke stap in de database? Verstuur je de request naar de server asynchroon en hoe lang duur het voordat die afgewerkt is?

[André]

Je moet de innerHTML functies vervangen voor DOM functies, dat gaat waarschijnlijk veel sneller werken.

En voor IE, dat hij steeds trager word kan liggen aan een vollopend geheugen omdat bepaalde objecten niet goed verwijderd worden. Maak je ergens constant veel nieuw objecten aan?

[Verwijderd]

Janoz schreef op woensdag 26 april 2006 @ 14:34:
Ik denk dat je idd dom bezig bent met innerHTML ..

Waarschijnlijk kun je je personage beter absoluut positioneren. Je hoeft dan immers alleen de top en de left aan te passen. Je hoeft dan niet meer een compleet nieuw plaatje te laden en je vorige tile te vervangen. Bijkomend voordeel is dat je de verplaatsing kunt animeren door in een loopje je plaatje te verplaatsen.

Heb ik overwogen.. levert problemen op. ik moet dan denken aan dingen zoals collision detection

[Janoz]

Bedoel je de animatie, of uberhaupt het gebruik van absolute positionering?Bij de eerste kan ik het me voorstellen. Er is verder weinig verschil. Je werkt nog steeds met tiles. Het enige verschil is dat je bij de ene nieuwe plaatjes laat terwijl je bij de andere gewoon een bestaand plaatje ergens anders neerzet.

[Verwijderd]

Gunp01nt schreef op woensdag 26 april 2006 @ 14:34:
Je schrijft dus bij iedere stap in de database? Het lijkt me dat er betere manieren zijn om je gamestate te persisten in dit geval (gewoon een in-memory object aan serverzijde).

Ik kan zo niet precies ruiken hoe je het e.e.a. geimplementeerd hebt, maar wacht je presentatielaag tot de server klaar is met het wegschrijven van elke stap in de database? Verstuur je de request naar de server asynchroon en hoe lang duur het voordat die afgewerkt is?

'gewoon een in-memory object' klinkt toch tikkeltje ingewikkelt.. wat moet ik daarvoor doen? Ik heb wel iets gelezen over persistent connections.. maar schijnt nogal bottleneck te worden als er veel gebruikers zijn. Mijn bron komt van een voorganger, (voor zover i kweet de enige) die ook bezig is geweest met mmorpg's in javascript. correct me if im wrong.. Laat ik het zo zeggen.. het spel moet ook werken op een enkele server bij een 2e keus hosting. Ik heb geen geld en verdien er niks aan. multiserver kan ik voorlopig helemaal forgetten

De server wacht niet op het wegschrijven.. Dankzij het ajax gebeuren zou de boel asynchroon moeten lopen. de refreshes van 350milliseconden gebeuren, naar mijn weet onafhankelijk van het submitten van je locatie als speler. De tijden die het script er over doet, zijn verwaarloosbaar... ik doe microtimechecks tussen mijn scripts.. en die geven miniscule tijden. Het feit dat alleen IE met dit probleem kampt, doet mij vermoeden dat het probleem client side ligt.

[djluc]

"'gewoon een in-memory object'"
In iets als PHP bijvoorbeeld een SESSION... In andere talen kan je zelfs een complete applicatie open laten staan.

[ Voor 13% gewijzigd door djluc op 26-04-2006 15:15 ]

[Verwijderd]

Janoz schreef op woensdag 26 april 2006 @ 15:07:
Bedoel je de animatie, of uberhaupt het gebruik van absolute positionering?Bij de eerste kan ik het me voorstellen. Er is verder weinig verschil. Je werkt nog steeds met tiles. Het enige verschil is dat je bij de ene nieuwe plaatjes laat terwijl je bij de andere gewoon een bestaand plaatje ergens anders neerzet.

Ik bedoel het absoluut positioneren.. als ik als speler een steen of een huis tegenkom.. of een medespeler.. dan moet er iets van collision detection zijn om te weten dat je ergens tegenop loopt.
Met dit tile gebeuren is het een kwestie van je eigen tile + 1 voor rechtsaf, eigen tile -1 voor links, eigen tile + tilebreedte voor omlaag... etc.. location: absolute; left: 34, right: 22.. is dat in collission met huis die staat in tile 5, 6,7, 20, 21,22, 35, 36, 37? Gaat mij te boven

[Verwijderd]

André schreef op woensdag 26 april 2006 @ 14:36:
Je moet de innerHTML functies vervangen voor DOM functies, dat gaat waarschijnlijk veel sneller werken.

En voor IE, dat hij steeds trager word kan liggen aan een vollopend geheugen omdat bepaalde objecten niet goed verwijderd worden. Maak je ergens constant veel nieuw objecten aan?

document.getElementById(playerlocation).value; ? doet hetzelfde als:

document.getElementById(playerlocation).innerHTML; qua performance.. innerHTML is toch al onderdeel van het document object model?

[Verwijderd]

djluc schreef op woensdag 26 april 2006 @ 15:14:
"'gewoon een in-memory object'"
In iets als PHP bijvoorbeeld een SESSION... In andere talen kan je zelfs een complete applicatie open laten staan.

Ok..volgens mij snap ik wat je bedoeld.. maar alles wat ook maar heeft te maken met sessies, memory en alles wat daarnaar ruikt of proeft, is natuurlijk niet gedeeld met je medespelers.. ik als speler wil toch elke fractie van een seconde weten waar jij naartoe bent gelopen.. ik wil je realtime zien lopen.

[JHS]

djluc: PHP slaat by default sessies op in een file . Dat iets persistent is wil volgens mij niet zeggen dat het een in-memory object is .

[djluc]

Er zijn trucjes om andermans sessies uit te lezen. Alleen kan je die niet toepassen op schared hosting mag ik hopen... Waar je eigenlijk moet beginnen is: Meet wat precies de vertragingen veroorzaakt. Is het de server die traag reageert, heeft die elcheapo hoster gewoon een trage verbinding, werkt je script niet goed (memory leaks) of is er nog iets heel anders aan de hand? Ik gok op een memory leak...

[Not Pingu]

Verwijderd schreef op woensdag 26 april 2006 @ 15:10:

'gewoon een in-memory object' klinkt toch tikkeltje ingewikkelt.. wat moet ik daarvoor doen?

Of en hoe het in PHP kan, weet ik niet.
Maar wat ik je kan aanraden is om het servicegeorienteerd op te zetten (wat vaak samengaat met AJAX / Rich Internet Apps).

Daarmee bedoel ik het volgende:
- je clientside stukje (DHTML in webpage) is er puur en alleen om de gamestate te visualiseren en om de speler commando's te laten geven
- het clientside deel stuurt de gegeven commando's door naar de server die ze interpreteert, valideert en de gamestate update
- elke client vraagt dus de volledige gamestate op en geeft die weer
- je kunt de gamestate eventueel backuppen in een bestand of in de database, zodat je hem snel weer kunt opvragen mocht je in-memory object op de een of andere manier weggegooid worden.

Als je er echt een MMORPG van wilt maken, kun je de gamestate niet in een session opslaan, maar moet je die centraal opslaan zodat alle clients dezelfde gamestate hanteren.

[Janoz]

Verwijderd schreef op woensdag 26 april 2006 @ 15:16:
[...]


Ik bedoel het absoluut positioneren.. als ik als speler een steen of een huis tegenkom.. of een medespeler.. dan moet er iets van collision detection zijn om te weten dat je ergens tegenop loopt.
Met dit tile gebeuren is het een kwestie van je eigen tile + 1 voor rechtsaf, eigen tile -1 voor links, eigen tile + tilebreedte voor omlaag... etc.. location: absolute; left: 34, right: 22.. is dat in collission met huis die staat in tile 5, 6,7, 20, 21,22, 35, 36, 37? Gaat mij te boven

Daar hoeft toch ook niks aan te veranderen? Een speler staat nog steeds op een tile. Je hele tile code kan verder hetzelfde blijven. Je moet alleen iets in je render code aanpassen. ipv het vervangen van 2 tiles zet je de positie van je speler object ergens anders neer.

[André]

Verwijderd schreef op woensdag 26 april 2006 @ 15:17:
[...]


document.getElementById(playerlocation).value; ? doet hetzelfde als:

document.getElementById(playerlocation).innerHTML; qua performance.. innerHTML is toch al onderdeel van het document object model?

innerHTML is geen onderdeel van het DOM, innerHTML is een functie waarmee je de DOM op een ranzige manier kunt aanpassen. Het kan zijn dat innerHTML in sommige gevallen beter performed maar dat zul je moeten testen.

[Verwijderd]

djluc schreef op woensdag 26 april 2006 @ 15:24:
Er zijn trucjes om andermans sessies uit te lezen. Alleen kan je die niet toepassen op schared hosting mag ik hopen... Waar je eigenlijk moet beginnen is: Meet wat precies de vertragingen veroorzaakt. Is het de server die traag reageert, heeft die elcheapo hoster gewoon een trage verbinding, werkt je script niet goed (memory leaks) of is er nog iets heel anders aan de hand? Ik gok op een memory leak...

Ik ben dus zelf de host.. en de client..en hij doet het goed in Firefox.. ik denk dat het niet aan de server ligt, eerlijk gezegd. Hoe kan ik goed metingen verichten?

dit is wat ik nu doe:

$start = microtime();
...script
...script
$end = microtime();
echo "alert(\'($end-$start)\')";

[Verwijderd]

Gunp01nt schreef op woensdag 26 april 2006 @ 15:32:
[...]


Of en hoe het in PHP kan, weet ik niet.
Maar wat ik je kan aanraden is om het servicegeorienteerd op te zetten (wat vaak samengaat met AJAX / Rich Internet Apps).

Daarmee bedoel ik het volgende:
- je clientside stukje (DHTML in webpage) is er puur en alleen om de gamestate te visualiseren en om de speler commando's te laten geven
- het clientside deel stuurt de gegeven commando's door naar de server die ze interpreteert, valideert en de gamestate update
- elke client vraagt dus de volledige gamestate op en geeft die weer
- je kunt de gamestate eventueel backuppen in een bestand of in de database, zodat je hem snel weer kunt opvragen mocht je in-memory object op de een of andere manier weggegooid worden.

Als je er echt een MMORPG van wilt maken, kun je de gamestate niet in een session opslaan, maar moet je die centraal opslaan zodat alle clients dezelfde gamestate hanteren.

Ja daar gaat dus mijn probleem over.. nogmaals:

het is een ECHTE mmorpg... oftewel: multiplayer oftewel.. eenmalig een gamestate opslaan is prima, maar daar heb je geen reet aan, want die is na 350ms alweer veroudert. Mensen wandelen rond, zeggen dingen tegen elkaar etc. etc. Wat dus nu gebeurd is dat alles centraal opgeslagen is.. het ligt niet aan de server. ik ben zelf de host, en ik doe nu alles local.. bovendien doet firefox wel wat ik wil

[Verwijderd]

Janoz schreef op woensdag 26 april 2006 @ 15:34:
[...]


Daar hoeft toch ook niks aan te veranderen? Een speler staat nog steeds op een tile. Je hele tile code kan verder hetzelfde blijven. Je moet alleen iets in je render code aanpassen. ipv het vervangen van 2 tiles zet je de positie van je speler object ergens anders neer.

Volgens mij wil ik heel graag weten wat je oplossing is.. het klinkt veelbelovend. maar even om duidelijk uit te leggen wat mijn script doet:"

for(y=1;y<=SectorSum;y++)
{
if(TileStatus[y] != "blocked")
{
document.getElementById(y).innerHTML = ""; //schoonvegen speelveld
}
}
for(x=0;x<(players.length);x+=3)
{
document.getElementById(parseInt(players[x])).innerHTML = "[img]'img/"[/img]";
if(players[x+1] == user)
{
locationPlayer = parseInt(players[x]);
direction = players[x+2];
}
}


Er worden dus geen tiles vervangen..vervangen van object doe ik al.. toch?

[Not Pingu]

Verwijderd schreef op woensdag 26 april 2006 @ 16:04:
[...]


Ja daar gaat dus mijn probleem over.. nogmaals:

het is een ECHTE mmorpg... oftewel: multiplayer oftewel.. eenmalig een gamestate opslaan is prima, maar daar heb je geen reet aan, want die is na 350ms alweer veroudert. Mensen wandelen rond, zeggen dingen tegen elkaar etc. etc. Wat dus nu gebeurd is dat alles centraal opgeslagen is.. het ligt niet aan de server. ik ben zelf de host, en ik doe nu alles local.. bovendien doet firefox wel wat ik wil

Ja, dat bedoel ik nou juist. Het is een MMORPG dus moet je de gamestate centraal opslaan (niet in de session dus).
Het opslaan in een file of db (om de zoveel seconden ofzo) is enkel om daarop terug te kunnen vallen als je in-memory gamestate verdwijnt. Bij shared hosting heb je nl. in de regel om de zoveel minuten een restart van de webserver, waardoor je in-memory gamestate dus verdwijnt.

Juist omdat je gamestate per seconde 10x kan wijzigen, wil je niet iedere keer naar de database moeten schrijven. Een object in het geheugen is veel sneller op te vragen.

[BtM909]

Je kan even hier spieken of je een vertragings-factor heb in innerHTML vs. DOM: http://www.quirksmode.org/index.html?/dom/innerhtml.html

Ik denk zelf als het per stap trager wordt, dat je of je objecten niet goed opruimt of steeds nieuwe objecten erbij aanmaakt ipv huidige hergebruiken...

[Norm2782]

Wow, gaaf projectje!
Half OT: is de source beschikbaar?

[Janoz]

Stel je tiles zijn 100px bij 100px dan kun je exact de positie van elke tile bepalen. Dat is namelijk 100px * tile in x richting en 100px * tile in y richting.

Php is trouwens nauwelijks geschikt als realtime mmorpg omgeving. Dit komt doordat php geen application scope kent. Application scope is de ideale plek om gamestate van de game in op te slaan.

[crisp]

1) Je doet op deze manier veel lookups; probeer referenties naar DOM-elementen te cachen in een script-variabele (een array bijvoorbeeld)
2) geef je img een id ipv het containing element en pas enkel de src-property daarvan aan; innerHTML is hier echt overbodig en ws trager
3) ad 2) verwijs naar de src-property van een preloaded image ipv een url-toewijzing om te voorkomen dat de browser het plaatje opnieuw ophaalt van de server
4) zorg ook dat je de juiste cache-headers meestuurt voor images vanaf je server (met name een Expire header in de toekomst)

Verder vermoed ik ook dat je ergens een memory-leak triggert in IE, maar da's zonder volledige code moeilijk te beoordelen.

[ Voor 4% gewijzigd door crisp op 26-04-2006 16:31 ]

[Verwijderd]

In-Memory dus.. hmm.. dan moet ik daar maar eens verder op googelen. Ik weet mijn god niet hoe ik zoiets bewerkstellig. Dank je!

verder:

Norm2782 schreef op woensdag 26 april 2006 @ 16:27:
Wow, gaaf projectje!
Half OT: is de source beschikbaar?

Dank je :-) Het idee is op zich om het project, nadat ik er mee ben afgestudeerd, semi-opensource te maken. spelers kunnen inzendingen doen die dan in de meeste gevallen geimplementeerd worden. Het moet uiteindelijk een life-sim worden. Het project heeft nu als werknaam "Best of all Worlds" wat dubbelzinnig zegt, dat het enerzijds het beste is uit de bekende, reeds bestaande mmorpg's (+ nieuwe concepten die ik nog niet eerder heb gezien). en anderzijds, het beste uit alle webtechnieken. De kunst van dit project.. (of een van de kunsten) is om iets te maken waar je geen plugin voor nodig hebt, geen gecompilede shit, geen flash..puur javascript, php etc. wat iedereen kan gebruiken, en omdat alles dus in scripttaal is, is het toegankelijk voor meer developers. (bijdrage aan het spel in de vorm van design wordt ook zeer gewaardeerd natuurlijk)

Ik wil bewust geen 'talen' gebruiken.. alleen scripttalen.

[Verwijderd]

crisp schreef op woensdag 26 april 2006 @ 16:31:
1) Je doet op deze manier veel lookups; probeer referenties naar DOM-elementen te cachen in een script-variabele (een array bijvoorbeeld)
2) geef je img een id ipv het containing element en pas enkel de src-property daarvan aan; innerHTML is hier echt overbodig en ws trager
3) ad 2) verwijs naar de src-property van een preloaded image ipv een url-toewijzing om te voorkomen dat de browser het plaatje opnieuw ophaalt van de server
4) zorg ook dat je de juiste cache-headers meestuurt voor images vanaf je server (met name een Expire header in de toekomst)

Verder vermoed ik ook dat je ergens een memory-leak triggert in IE, maar da's zonder volledige code moeilijk te beoordelen.

1) --> hoe bedoel je? ik heb nu 1 array genaamd "Players" waar alles in zit.. alle spelers, met hun naam etc.. dit is een javascript array.. moet ik nu ook velden gaan cachen.. ? *dumb cow*

2) --> ik heb het vaak gezien, nooit gebruikt! ik ga het onderzoeken! dank je..

3) --> ik neem dit advies ten harte! ik dacht dat een preload script alleen genoeg was, en het script vanzelf kijkt in het cache naar gelijkenissen.
5) dit heb ik gedaan.. maar dan met expire headers in verleden. Probleem is dat ik op dit punt NIET wil dat IE gaat cachen.. hij maakt dan een cookie aan met mijn locatie.. en mijn poppetje komt dan niet meer van de grond.

[BtM909]

Waarom zou je die images op dat moment niet willen cachen

[Verwijderd]

wél de images, niet de locatie van de speler.. hij maakt een cookie aan.. die vervolgens er voor zorgt dat mijn poppetje aan de grond genagelt blijft. hiermee voorkom ik dat:

header("Expires: Sun, 19 Nov 1978 05:00:00 GMT");
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
header("Cache-Control: no-store, no-cache, must-revalidate");
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache");

[Verwijderd]

Gunp01nt of iemand anders.. waar kan ik een goeie source vinden voor "in-memory objects". Ik krijg in google resultaten alleen meuk.

[NetForce1]

Een paar minuten googelen leverde me de volgend resultaten op:
• http://zez.org/article/articleview/46/1/
• http://nl3.php.net/shmop

[Verwijderd]

dank je! nu maar hopen dat --enable-shmop ook wordt uitgevoerd door .htaccess file......

[killercow]

ahh leuk!

nog een ajax mmorpg.

Misschien leuk om (als je met je school opdracht klaar bent) te mixen met ons project?

http://www.pc-gamers.com/webgamex/iso_js_coords.php
De code hiervan is GPL, en bestaat uit een serie server files, een serie client-side files, en wat generators, voor het maken/renderen/shaden van de tiles/cursors, en het inladen van de map vanuit een grayscale png image. Ook hebben we code om dingen als a* path finding etc te doen op de server.

Onze wiki is trouwens hier te vinden:
http://cobra.innerheight.com/freevolution

Jouw tech requirements (geen closed source files, geen gecompiled zooi) is precies de onze,

[ Voor 25% gewijzigd door killercow op 26-04-2006 22:19 ]

[Verwijderd]

holy fok.. moet je ook maar zin in hebben :-p.. erg leuk om dit te zien. Denk je dat de performance nog omhoog kan ondanks dat er in een totale implementatie meer bij komt? Ik heb het idee dat bij het 'scrollen' (vraag is of je dat zo mag noemen), er nieuwe renders worden gemaakt..communicatie met de server? Het is me nog niet echt duidelijk of jullie commerciële doeleinden er mee hebben, en wat je er mee hoopt te kunnen bewerkstelligen.. Rollercoast Tycoon... is dat haalbaar? Sim City heeft er nu al moeite mee om de boel op zijn plek te krijgen in-time...Daar komt nog de meerwaarde van internet bij, dat je waarschijnlijk multiplayer ideeen er mee hebt.

Ik moet zeggen dat ik bewust heb gekozen voor een bovenaanzicht met een gefaked lichtelijk vooraanzicht.. je kunt genoeg details kwijt, terwijl je, eenmaal de graphics geproduceert, ze kunt hergebruiken na ze telkens een kwartslag te hebben gebruikt zonder dat het hele perspectief er verwrongen uit ziet. Zoals ik er nu naar uitkijk, zie ik graag een gameplay zoals Harvest Moon van de super nes, of beter bekend: The legend of Zelda... nintendo.. maar zelda op de supernes is qua graphics weer iets gelikter.

Nog een andere bron voor je.. zij hebben een goed werkend flash spel (helaas flash) met isometrisch aanzicht.. en super gave graphics! alles is heel geraffineerd getekend. klasse!
http://www.dofus.com/

[Verwijderd]

Trouwens Gunp01n2.. --enable-shmop is iets voor bij de installatie.. uhm.. standaard staat die niet ingeschakelt.. Zou dus betekenen dat ik het beestje zelf moet hosten Kan ik bij deze die oplossing schrappen? of zie ik iets over het hoofd?

aantal dingen die de revu gepasserd zijn kan ik dus proberen:

- absolute positioneren, alle mogelijke coordinaten klassificeren met een bijbehorende tile, en zo de tilenummer waar je karakter onder valt gebruiken zoals ik die nu gebruik voor 'collision detection'
met dank aan Janoz
- plaatjes precachen en bijbehorende objecten gebruiken voor de verwijzing, id's gebruiken in mijn image... in het proces kom ik wel achter wat je precies bedoeld.. ik denk dat het waardevol is om geen gebruik meer te hoeven maken van innerHTML.. uiteindelijk denk ik dat daar de key zit.
met dank aan Crisp
En de rest natuurlijk ook thanks.. ik ga het uitproberen.. to be continued...

[ Voor 4% gewijzigd door Verwijderd op 27-04-2006 01:19 ]

[killercow]

Als je scrollt worden er inderdaad tiles van de server gefetched, (en aan de andere kant weer gedestroyed), omdat het beestje nu op een oude celly 400 draait gaat dat behoorlijk langzaam. Het idee is dat we de buffer vergroten als de latency te hoog is, en zo de memmory load op de client wat verhogen.

Real-time graphics als roller-coaster tycoon wordt erg lastig vanwege de snelheid van de beweging. Transport tycoon achtige bewegingen moet echter geen probleem zijn.

We proberen zo veel mogelijk graphics te generaten via php (tiles/cursors/flora/fauna), waardoor wij/anderen heel gemakkelijk de graphics en look/fool kunnen aanpassen.

Het wordt inderdaad een mmorpg, de chat werkt ondertussen wel aardig, maar het hele update mechanisme zijn we aan het verbouwen zodat het meer zoals gmail-talk werkt. (met persistent http verbinden van enkele minuten ipv seconden.)

De map wordt dynamisch geladen zodat we bizar grote maps kunnen gebruiken zonder dat de client nog langer moet wachten. Straks wordt het scrollen uitgeschakeld, en scrollt de map om de user heen, zolang de user niet te hard beweegt, moet het scrollen van de map dus geen probleem zijn.

[Verwijderd]

Crisp you're a f*cking genius.. dat is dus inderdaad wat het probleem was.. ik heb nu elk veld gevuld met een blank.gif..bij de eerste load en overal waar een speler staat wordt de src aangepast bij iedere refresh.. waarschijnlijk kan het ook zonder blank.gif.. maar ik heb nu geen flikkerende objecten meer in ff en IE laat geen hourglass meer zien. Hij is denk ik ook sneller geworden, maar nog wel te langzaam.. ik ga nog zoeken naar memory leaks. thanks again.

case closed..

[Janoz]

@killercow:

Als ik jou was zou ik overwegen om niet alle plaatjes te genereren, maar veel met kant en klaar images gaan werken die eventueel op de client opgeslagen staan.

Ik heb een keer een online spel gezien waar je zelfs alle graphics kon downloaden en lokaal op kon slaan. De lokatie werd in een cookie gezet zodat alle plaatjes zelf van je eigen HD werden gehaald (geen idee of het tegenwoordig nog kan vanwege security). Het ontlast je server behoorlijk zodat deze zich met de werkelijke servertaken bezig kan houden.

[Blaise]

Ik heb een keer een online spel gezien waar je zelfs alle graphics kon downloaden en lokaal op kon slaan.

Vasili wou juist toegankelijkheid, en voor mij zou zoiets een belemmering zijn.


Trouwens: als een server elke 350 ms een request in PHP moet verwerken, en er connecten 20-30 mensen tegelijk, kan een server dat wel aan?

Ik had laatst namelijk een simpele chat (eigenlijk meer multiplayer notepad) gemaakt met AJAX/PHP die elke 100 ms refreshte, en met vijf mensen tegelijk ging de CPU van Apache al op 90%. Daarmee had ik voor mijzelf geconcludeerd dat AJAX+PHP niet geschikt is om dingen mee te 'streamen' die constant voor meerdere mensen tegelijk een snelle response van < halve seconde vergen, omdat dat gewoon te zwaar is.

[killercow]

@janoz,

de grahics worden eenmalig door de server gegenerate en geshade met php en gd, daarna zijn ze gewoon op de server beschikbaar.
Eventueel kunnen mensen ze in een later stadium wel lokaal opslaan, maar dan moet je ook je firefox config weer tweaken om het mogenlijk te maken lokale images in de externe html te laden.

@blaise
Het idee van een persistent connectie is dat je http pagina nooit klaar is, maar dat hij eigenlijk in een end-less loop door blijft lopen, doordat de browser continue nieuwe javascript die binnenkomt gaat executen kun je dus elke ms een bericht naar de browser sturen als je dit wilt., nadeel is dat je per client, 1 apache child open hebt staan, en eventueel dus de bijbehorende script taal.
volgens mij kun je dan beter een losse http server in python schrijven die zoiets kan afvangen, en alsnog gewoon zijn gegevens uit de database en files kan visssen.
Een server met een shared memmory oplossing zou nog mooier zijn, maar tjah dan ben je al wel erg ver van je originele apache oplossing verwijderd.

Ik heb een cluster van dual p3's dus ik kan het eventueel in een live omgeving wel hebben, maar leuk is anders.

[NetForce1]

Verwijderd schreef op donderdag 27 april 2006 @ 14:24:
Crisp you're a f*cking genius.. dat is dus inderdaad wat het probleem was.. ik heb nu elk veld gevuld met een blank.gif..bij de eerste load en overal waar een speler staat wordt de src aangepast bij iedere refresh.. waarschijnlijk kan het ook zonder blank.gif.. maar ik heb nu geen flikkerende objecten meer in ff en IE laat geen hourglass meer zien. Hij is denk ik ook sneller geworden, maar nog wel te langzaam.. ik ga nog zoeken naar memory leaks. thanks again.

case closed..

Is het niet makkelijker om voor de speler een plaatje met transparante background te gebruiken, zodat je alleen de positie maar hoeft aan te passen?

[Verwijderd]

NetForce1 schreef op donderdag 27 april 2006 @ 19:26:
[...]

Is het niet makkelijker om voor de speler een plaatje met transparante background te gebruiken, zodat je alleen de positie maar hoeft aan te passen?

haha.. ja dat is makkelijker.. dat was ook de oorzaak van mijn probleem en de oorzaak voor dit forum maar thanks!

Wat betreft die connecties..sja.. dat word nog een uitdaging.. ik ga maandag een test doen en ik hou mijn hart vast...Als het niet lukt met veel mensen online, dan zal ik denk ik toch op deze manier verder moeten gaan in ieder geval tot het examen.. en daarna moet ik zoeken naar mogelijkheden om zelf de luxe te hebben over een server die ik zelf kan instellen. Ik begin door jullie overtuigd te raken dat in-memory object de oplossing is voor dit soort geintjes.

100ms voor je chatprog. is aardig snel.. is dat wel nodig? Ik heb er ook een chatvenster in, en die gaat prima op 350 ms..scheelt denk ik wel...Ik hoop er in elk geval mee door mijn examens mee te komen bij wijze van demo.. maar het liefst wil ik er ook mee doorgaan na mijn school. ik ben ontmoedigd..