[dhtml] clipping van grote afbeeding, ipv erg veel kleintjes

[killercow]

Ik ben al tijden bezig met een dhtml game engine waarin ik kleine png plaatjes gebruik als map, deze plaatjes zijn allemaal ongeveer 0.8k groot en omdat het er een hele boel zijn (ongeveer 1500) duurt het tijden voor ze allemaal binnen zijn.

De images nemen op disk ieder 32kb is wat natuurlijk niet handig is, zowel op de server als op de client niet. daarnaast geeft alles ook nog een enorme overhead tijdens het downloaden (http headers, png headers, png color table) wat allemaal opgelost kan worden doro een grote plaat te gebruiken met al deze kleine files rin geplaatst (sprites dus)

De browser wordt nu als ik mijn map laad met 2500 layers (minimaal) volledig op zijn kieen gedwongen (zelfs op een xp3000+). javascript optimalisaties zijn er bijna niet meer, heb al van alles geprobeerd maar nu bedacht ik dat de browser wellicht een stuk efficienter zou kunnen opgaan met een grote plaats ipv al die kleintjes. dit gecombineerd met clipping (net zo als crisp het heeft in lemmings/pumpkins) zou toch tot het zelfde eind resultaat moeten komen.

Nu is mijn vraag:
Is een browser inderdaad sneller aan het werken met een grote plaat ipv al die kleintjes
Of laad de browser nog steeds 1500 keer de volledige plaat in zijn geheugen om hem daarna 1500 x te knippen (wat uiteraard WAY langzamer is)

(testen duurt zeker met mijn code nu best eventjes op te bouwen, daarom vraag ik het eerst)

Hier een screeny.

[djluc]

Bij menuutjes e.d. wordt een afbeelding ook altijd maar 1x geladen. Dat zou je dus, mits je snel kunt slicen, een goede winst op kunnen leveren. Alleen het slicen lijkt me een vrij intensieve taak.

[BtM909]

Vanochtend las ik hier toevallig een artikel over sprites: http://www.alistapart.com/articles/sprites, waarbij idd een soort techniek als gebruikt in Pumpkins aan bod komt

edit:

Wat zijn klentjes trouwens

[ Voor 12% gewijzigd door BtM909 op 08-03-2004 16:22 ]

[killercow]

BtM909 schreef op 08 maart 2004 @ 15:48:
Vanochtend las ik hier toevallig een artikel over sprites: http://www.alistapart.com/articles/sprites, waarbij idd een soort techniek als gebruikt in Pumpkins aan bod komt

Ik hem gelezen maar ze gebruiken een oplossing die ik helaas niet gemakkelijk kan implementeren.

Verder wel een interesant stukje tekst.
Heeft iemand hier al eens mee gespeeld?

[André]

Leuke map trouwens, doet me denken aan een combo van Transport Tycoon en Simcity.

En ik denk dat heel veel kleine plaatjes toch efficienter is dan een paar grote. Het is nou eenmaal zo dat IE+DHTML geen hoogstaande graphics aan kan.

Edit:
Bij nader inzien: misschien een mooi gemiddelde daar tussenin. Dus zolang de plaatjes niet al te groot worden, kun je plaatjes die bij elkaar horen wel in 1 image zetten. Daar zul je een beetje performance halen.

Edit2: Correctie, IE+DHTML moest zijn JS+DHTML, maar dat is ook onzin dus eigenlijk bedoel ik DHTML

[ Voor 44% gewijzigd door André op 08-03-2004 16:20 . Reden: simcity niet, toch tycoon ]

[killercow]

IE+dhtml is eigenlijk ook niet mijn goal,
als mensen firebird nodig hebben om mijn game te spelen dan is dat maar zo, (firebird install is ook niet zo'n vreselijk groot probleem denk ik) Een gecko (firebird/mozilla) only oplossing is watmij betreft ook oke, dan kan ik altijd nog een alternatieve ie versie beschikbaar maken.

de eerste tiles die ik gebruikte kwamen inderdaad uit transport tycoon, alleen heb ik veel meer features aan de terrain engine toegevoegd (oa transparant multi-layer water, groter verval mogenlijk tussen verschillende tiles)

[crisp]

Mijn ervaring met sprites is dat je ook niet teveel elementen in je sprite moet gaan stoppen, want dat vertraagd de boel juist weer enorm. Dus 1 groot plaatje met daarin al je elementen is een absolute no-go...

[killercow]

hmm, dat compliceert de zaak behoorlijk, ik zal eens nadenken hoe ik netjes een laag kan schrijven die dit voor me op lost, aangezien ik geen zin heb om alles met de hand uit al die losse sprite files te gaan halen.
ik zit nu te denken aan een type ground texture per sprite file, en dan eventueel de andere objecten in de map ook gegrouped in een setje sprite files.

Iemand anders nog heldere ideen?

[André]

killercow schreef op 08 maart 2004 @ 21:20:
hmm, dat compliceert de zaak behoorlijk, ik zal eens nadenken hoe ik netjes een laag kan schrijven die dit voor me op lost, aangezien ik geen zin heb om alles met de hand uit al die losse sprite files te gaan halen.
ik zit nu te denken aan een type ground texture per sprite file, en dan eventueel de andere objecten in de map ook gegrouped in een setje sprite files.

Iemand anders nog heldere ideen?

Hmmjah, ik ben eigenlijk wel benieuwd wat je precies van plan bent, is datgene wat je wilt niet te zwaar voor een browser? Als we weten wat je wilt kunnen we ook gerichtere tips geven.

[killercow]

Wat ik uiteindelijk wil bereiken is dat ik een isometrische map kan showen in een browser opgebouwd uit allemaal kleine tiles.

De map moet dmv dhtml scroll de juiste nieuwe rijen tiles ophalen van de server via dhtml en deze dan ook weergeven, uiteraard mogen er aan de andere kant dan tiles wegvallen/gecleaned worden,

hierdoor kan ik een viewport defineren met een x aantal tiles erin, (dus je kan de engine aanpassen aan de snelheid van de gebruikende pc), tevens heb ik grotere tiles zodat er met verschillende resoluties toch een volledig beeld vullende engine gebruikt kan worden. (je kunt dus een lagere resolutie kiezen in de engine als je pc het niet trekt, je ziet dan gewoon minder.)
Het dynamisch laden van de tiles heb ik op het moment nog geen oplssing voor, het toevoegen/verwijderen van de objecten aan de DOM is geen probleem, alleen doordat er verschillende hoogte levels in de map zitten weet ik nog niet waaneer ik een rij kan droppen/een nieuwe moet ophalen. (alle rand tiles nalopen en dan kijken of de buur tile in de viewport zit, maar nog niet gefetched is is een mogenlijkheid)

De dhtml scroll is ook al redelijk af, hij werkt in principe wel aardig, aleen is dus ook veel te traag.

[André]

Met goede berekeningen kun je zo bekijken welke tiles er binnen de viewport vallen, dat hoeft dus geen probleem te zijn. Je zou dus ook alles al kunnen inladen (qua plaatjes ed) want je hoeft alleen het zichtbare gedeelte te scrollen/animeren.

Er is hier op GoT wel eens een test geweest over de snelheid van js animaties: hoeveel elementen konden er tegelijk soepel geanimeerd worden. De resultaten vielen geloof ik wel tegen, het doel dat jij voor ogen hebt gaat IMHO een hele grote pc vragen.

En kun je ipv DHTML scroll geen normale scroll gebruiken?

[ Voor 6% gewijzigd door André op 09-03-2004 11:13 ]

[killercow]

Normale scroll zou kunnen, alleen deze geeft een vervelend effect (nieuwe render van de browser viewport waardoor je strepen krijgt blijkbaar),

Ik weet dat het animeren van een groot aantal afbeeldingen erg zwaar is, daarom staan ze allemaal in een grote layer welke ik verschuif, dit helpt al een stuk omdat de posities van alle kleine images tenopzichte van de parent layer niet veranderen.

Aangezien ik maar een gering aantal afbeeldignen echt wil laten bewegen moet het denk ik wel te doen zijn,

Het scrollen van de map, en dan uitrekenen welke nieuwe tiles er opgehaald moeten worden is op zich nog niet zo'n probleem, ik heb de formules om de tiles op de juiste plek te zetten ook geschreven maar deze kent de 3 coordinaten van de tiles, (xyz) en daarom kan ze zo op het scherm dumpen,
De functie in de browser kan echter alleen maar gissen of hij aan de linker kant tiles moet bij plaatsen die 32px breed zijn of maar 2 pixels, dit omdat de z as niet bekend is in dat script en het dus op de tast bekeken moet worden of er tiles nodig zijn om de viewport te vullen.

dhtml en normale scroll zijn trouwens ongeveer even snel op het moment, alleen de normale geeft strepen en fuck up scroll bars, terwijl de dhtml scroll de map lichtjes uit elkaar trekt en daarna weer in elkaar duwt.

[Dr_Frickin_Evil]

Ik weet niet zeker of ik je goed begrijp, maar is het geen optie om ipv afbeeldingen, gewoon achtergrondkleuren te gebruiken? Het wordt er uiteraard niet mooier op, maar qua performance zal het vast een hoop schelen.

[killercow]

uhm, nee ik denk inderdaad niet dat je me snapt,

hoe the f kan ik nou een isometrische engine bouwen met vierkante !! achtergrond hokjes, das best wel onmogenlijk.

ik ben ondertussen bezig met de implementatie van een aantal grotere sprites.