lasengine-devel Mailing List for LASengine (Page 2)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Aqui hi ha les dependències que es necessiten per compilar LASengine.

subversion
g++
build-essential
liblua50-dev
liblualib50-dev
libsdl-dev
libsdl-image1.2-dev
libsdl-ttf2.0-dev

HA HA HA, ES QUE ME DESORINO
Good Job!

2009/1/27 Matisoft <lle...@gm...>

> Developer!! Memory leak solved!!
>
> El problema era que els textos eren una SDL_Surface, i s'havien de lliberar
> amb SDL_FreeSurface!
>
> He creat la classe text, per poder imprimir i mantenir guardat el text el
> temps que desitjem.
> Falta que poguem passar per parametre múltiples variables, ja ho
> controlarem :)
>
> ALEGRIA DEVELOPER! AVUI ÉS UN GRAN DIA!! :D
>

Developer!! Memory leak solved!!

El problema era que els textos eren una SDL_Surface, i s'havien de lliberar
amb SDL_FreeSurface!

He creat la classe text, per poder imprimir i mantenir guardat el text el
temps que desitjem.
Falta que poguem passar per parametre múltiples variables, ja ho controlarem
:)

ALEGRIA DEVELOPER! AVUI ÉS UN GRAN DIA!! :D

Jo sé com fer-ho... si vols quan arribi a casa ho faig. És molt senzill i no
s'ha de modificar cap funció.
Ferran

2009/1/26 Matisoft <lle...@gm...>

> El problema bàsic, com et vaig comentar ahir, és que a cada mergeSurface
> creem una Surface nova, i això és el k fa que pugi, perquè de les 3
> animacions parcials, si creem 3 surfaces noves, només n'aprofitem la última
> (el game.cpp s'encarrega d'eliminar l'última Surface un cop l'ha dibuixat a
> pantalla) per tant en sobren 2.
>
> He estat provant de retocar-ho però no hi ha manera... El problema és que
> s'han de crear noves Surfaces, ja que primer anem a "baix nivell" i creem
> una SDL_Surface, i per tant després necessitem embolcallar-ho en una Surface
> per passar-ho a l'Sprite.
>
> Ho he provat creant una Surface desde Fora del merge, i passar-li per
> paràmetre, i a dins la funció fer un delete primer i després l'assignació
> del new, però peta, i encara no sé perquè.
>
> No faig commit ni re perquè seria pitjor, aniré provant i a veure si me'n
> surto!
>
> Fins després!
>
>

El problema bàsic, com et vaig comentar ahir, és que a cada mergeSurface
creem una Surface nova, i això és el k fa que pugi, perquè de les 3
animacions parcials, si creem 3 surfaces noves, només n'aprofitem la última
(el game.cpp s'encarrega d'eliminar l'última Surface un cop l'ha dibuixat a
pantalla) per tant en sobren 2.

He estat provant de retocar-ho però no hi ha manera... El problema és que
s'han de crear noves Surfaces, ja que primer anem a "baix nivell" i creem
una SDL_Surface, i per tant després necessitem embolcallar-ho en una Surface
per passar-ho a l'Sprite.

Ho he provat creant una Surface desde Fora del merge, i passar-li per
paràmetre, i a dins la funció fer un delete primer i després l'assignació
del new, però peta, i encara no sé perquè.

No faig commit ni re perquè seria pitjor, aniré provant i a veure si me'n
surto!

Fins després!

Ja esta tot ordenat com hem dit! :-)

Funciona l'ordre de les Z en el _activePartial. (fixa't k el barret l'he
posat per sobre el corn)

Però ara no se perquè, les posicions dels offsets kden malament... això s'ha
de mirar, és lo pròxim a fer.

Fins aviat! :-)

Bones Developer,

T'explico el maldecap.

La diferència entre fer un Hash i un Vector no és tant trivial, i s'ha de
pendre una decisió JA.
He estudiat totes les possibilitats, m'agradaria parlar-ne amb tranquilitat,
però bé, crec que parlant-ho per aquí i decidint alguna opció ja podem tirar
endavant, no podem allargar més la implementació de l'sprite, almenys de la
part de que estem tractant, amb les animacions parcials.

Et comento:

*Animacions Totals:*

Com que només necessitem tenir activa 1 animació total. Si guardem el
parametre _activeTotal, en tenim suficient, pk així sabem la que hi ha
activa a cada moment.
Pel que fa el conjunt d'animacions totals (que es carreguen al principi) no
necessiten cap ordre concret, i és més, com que quan l'hem de pintar accedim
mitjançant el nom de _activeTotal, un* HASH* és perfecte, perquè esta ben
ordenat, i el cost és O(1) en la cerca (si fos un vector, l'hauriem de
recorrer sempre).

Per tant, les totals estan bé!

-------------------------------------------------

*Animacions Parcials:*

Hi ha un problema de compromís, és a dir.

Necessitem que les Parcials estiguin ordenades per Z (per alhora de
pintar-les, pintar-les per ordre de profunditat).

Si implementem amb un Hash, esta molt bé perquè accedim directament a les
animacions que volem per el seu nom, però no les podem tenir ordenades... i
cada cop que fem la crida update de l'sprite, haurem de complicar-nos la
vida ordenant en temps real en un vector auxiliar abans de fer el merge...

Si ho intentem amb un vector, és bona idea perquè llavors ho podem inserir
ordenadament i sempre tindrem la llista ordenada. El problema és que
llavors, quan volguem sapiguer quines de les animacions que estan al vector
són actives, haurem de recorrer tot el vector de _activePartial per saber si
aquella en concret esta activa.

--------------------------------------------------

Així doncs el problema resumit és:

- Si fem *hash* perdem l'ordre per Z.
- Si fem *vector* perdem la rapidesa en cercar si l'animació és activa.

Personalment, la meva *proposta* és *posar un paràmetre "_active" a la
Animació Parcial*. Perquè així, podrem tenir el vector ordenat i només farem
un recorregut "N" per tot el vector. de l'altre manera fem
N*conjunt_actives.
A més la decisió bé de que la cerca l'hauràs de fer a l'activació d'una
parcial (buscar l'animació, i modificar parametre _active). però això no és
una operació que es fa a cada frame, així que és molt més eficient (i no
estic parlant de temps d'execució, sino de sentit comú).

Espero que m'hagi explicat bé! Diga'm que et sembla la proposta, perquè
suposa afegir un parametre a AnimPartial i creia que era oportú comentar-ho.

Fins aviat!

Hola Developer,

He fet la Hash Table per les animacions Totals i Parcials. Per fi ja
funciona!!!

Si apretes la tecla amunt i avall amb les fletxes, podràs veure com el corn
desapareix i torna a apareixer! (fa una cosa rara depen del'ordre de les
tecles, pero no en facis cas).

Bé, la hash table funciona i he decidit fer-la en comptes del vector perquè
és molt més directe, i més eficient pel que es vol fer.

Si ho féssim amb un vector, hauriem de reccorre'l tot per buscar cada
animació, amb la hashtable fas un "find" i en principi és directe.

Ja en parlarem una mica, però funciona mlt bé! Ara només hem de mirar la
lliberació de memòria.

P.D. El superguerrer encara no l'he pogut posar :S pero en principi t'hauria
de ser facil provar-lo... (suposo k fent activarPartial ja va) :-)

he vist més o menys que era... des del game.cpp es creaven surfaces que no
es destruien.. he posat deletes.

Abans el top em pujava un 0'1% de RAM cada 1 segon, i ara es cada 6.... hem
millorat en algo xD

2009/1/22 Ferran Galí <fer...@gm...>

> Si. Ho vaig posar perquè sino no enganxava el colorkey a sobre de
> l'animacio base (i per tant, borrava coses)
>
> Top es una comanda per mirar els processos com treballen.
>
> La memoria jo crec que la tenim controlada (vull dir, que no es deixa
> merda), lo que haurem de buscar una manera d'allibrear-la mica en mica, i no
> que ho faci al tancar el programa.
>
> 2009/1/22 Matisoft <lle...@gm...>
>
>> Has mirat el comentari k t'he fet del 7.2 setColorKey al merge surface?
>>
>> Ja em miraré lo de la memòria, que vols dir amb el top ences? :S
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> SourcForge Community
>> SourceForge wants to tell your story.
>> http://p.sf.net/sfu/sf-spreadtheword
>> _______________________________________________
>> Lasengine-devel mailing list
>> Las...@li...
>> https://lists.sourceforge.net/lists/listinfo/lasengine-devel
>>
>>
>

Si. Ho vaig posar perquè sino no enganxava el colorkey a sobre de l'animacio
base (i per tant, borrava coses)

Top es una comanda per mirar els processos com treballen.

La memoria jo crec que la tenim controlada (vull dir, que no es deixa
merda), lo que haurem de buscar una manera d'allibrear-la mica en mica, i no
que ho faci al tancar el programa.

2009/1/22 Matisoft <lle...@gm...>

> Has mirat el comentari k t'he fet del 7.2 setColorKey al merge surface?
>
> Ja em miraré lo de la memòria, que vols dir amb el top ences? :S
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Lasengine-devel mailing list
> Las...@li...
> https://lists.sourceforge.net/lists/listinfo/lasengine-devel
>
>

Has mirat el comentari k t'he fet del 7.2 setColorKey al merge surface?

Ja em miraré lo de la memòria, que vols dir amb el top ences? :S

Hola,

Tenim un problema greu d'ocupació de memòria... prova de deixar el LASengine
obert una estona, amb el "top" també encès.

Fixa't com puja la ocupació de ram.

Per cert, ja funciona bé el mergeSurface. Fallava una xorrada

Ferran

http://elvex.ugr.es/decsai/java/pdf/8D-TDD.pdf
mira't la pagina 3

2009/1/20 Ferran Galí <fer...@gm...>

> Hola Developers (encara que millor dit... developer!)
> http://gamesfromwithin.com/?p=29
>
> Mira't això, trobo que pot ser interessant aplicar Test Driven Development
> a LAS. De la manera que ho estem fent, es a dir, començant per baix i anant
> cap a dalt, pot ser bastant útil.
> Ens pot ajudar molt a saber exactament el que hem de fer i com ho hem de
> fer.... el meu dubte era que per tenir gràfics i tal potser no seria
> aplicable, però veient aquest article veig que pot ser possible.
>
> Què et sembla provar-ho? Si ho fessim, s'hauria de veure quin framework de
> tests ens pot ser més útil.
>
> Ferran
>

Hola Developers (encara que millor dit... developer!)
http://gamesfromwithin.com/?p=29

Mira't això, trobo que pot ser interessant aplicar Test Driven Development a
LAS. De la manera que ho estem fent, es a dir, començant per baix i anant
cap a dalt, pot ser bastant útil.
Ens pot ajudar molt a saber exactament el que hem de fer i com ho hem de
fer.... el meu dubte era que per tenir gràfics i tal potser no seria
aplicable, però veient aquest article veig que pot ser possible.

Què et sembla provar-ho? Si ho fessim, s'hauria de veure quin framework de
tests ens pot ser més útil.

Ferran

if (milliIncr != 0.f) //To avoid division by zero.
{
_milliseconds = 1000 / _fps * milliIncr;
}

Matias, lo que has fet a la revisió 44, posant (int) milliIncr està
malament... milliIncr sempre és un numero entre 0 i 1... si ho converteixes
a integer fas que sigui 1, i aleshores li treus tot el sentit.

Ho he deixat tal com estava.

Salutacions,
Ferran

Ei hola!

M'he trobat amb alguns problemes i he vist que pot ser util afegir aquesta
norma al programar (de fet, ja he refactoritzat tot el codi).
Els atributs privats d'una classe, posar-los de la seguent manera:
"_nomdelattribut" enlloc de "nomdelatribut"

Ho he fet perquè no hi hagi conflictes als setters:
void setNomDelAtribut(nomdelatribut)
{
   _nomdelatribut=nomdelatribut;
}

Salutacions,
Ferran

2008	Jan	Feb	Mar	Apr	May	Jun	Jul (2)	Aug	Sep	Oct	Nov	Dec
2009	Jan (17)	Feb (6)	Mar	Apr (2)	May (4)	Jun (5)	Jul (5)	Aug	Sep	Oct	Nov	Dec
2010	Jan (1)	Feb (3)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

lasengine-devel Mailing List for LASengine (Page 2)

lasengine-devel — Developer discussion