discussão sobre interface interna do event loop. #73
RodrigoDornelles
started this conversation in
General
Replies: 1 comment
-
depois de muito pensar, tenho uma idéia de uma solução para zeebo_module.require(std, game, application)
:package('@draw', engine_draw)
:register(register_events)
:run() lovelocal function register_events(std, game, aplication, func)
love.update = func('loop')
love.draw = func('draw')
end nativelocal event = {}
function native_callback_loop()
application.callbacks.loop(std, game)
event.loop()
end
local function register_events(func)
event.loop = func('loop')
event.draw = func('draw')
end gingalocal function register_fixed_loop(std, game, application, func)
local loop = func('loop')
local draw = func('draw')
local tick = function()
local delay = application.internal.fps_controler(event.uptime())
loop()
draw()
event.timer(delay, tick)
end
event.timer(1, tick)
end
local function register_event_loop(std, game, application, func)
event.register(func('ginga'))
end |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Problema
Depois de mais uma refatoração no eventloop da engine, percebi que a solução que estava tentando implementar não é tão adequada a todos aos cores
ginga
enative
, assim vou voltar atrás na alteração das interfaces. mas manter parte do trabalho. mas ainda não estou 100% satisfeito, pois mecanismos internos não estão encapsulados e também o objetoapplication
está sobrecarregado de responsabilidades que não o pertence, isso também impacta a trabalhar com launchers de games.Alteração b8d5c15
foi pensado na seguinte alteração, onde o objeto
root
além destd
,game
eapplication
também possuaevent
einternal
.apartir de agora a table
event
conteria eventos para modulos terem independencia em escrever suas callbacks e manipular o comportamento da engine.como ficaria a interligação do backend love2d com a própria engine.
débitos
native
não vejo problema nessa manipulação da global
event.update
do love, pois é um software de terceiro e uma camada de adptação, mas por exemplo eu fazer isso com o core nativenative_callback_loop
está fora de questão, pois seria uma adptação em cima do próprio software, algo que deveria ser resolvido de outra forma.como
event
einternal
foram criados internamente dezeebo_module
como passar para fora, alias cria-los por fora começa a deixar um design feio de código.além de que também no core native não a necessidade de adicionar modulos de sistema como
@draw
e@loop
indiretamente, pois a implementação é simples e eficazginga
em ginga teria que trabalhar com
event.register
eevent.timer
porém, além do nomeevent
já conflitar com a própria interface do ginga, como que seria exposto o mesmo objeto de maneira limpa?tentativas de soluções
criar o metodo
:register
emzeebo_module
podendo ter um nome melhor, foi uma solução que pensei que se encaixaria perfeitamente tanto no ginga quanto no love, mas ainda não consegui pensar em uma maneira que ficase bom para o core native.
love2d
ginga
instanciar
event
einternal
como globais.sem muito mistério, é uma solução feia mas resolve o problema.
o que me parece mais sujo, é que além de
.require
ficar sobrecarregado de parametros. parece perder a relação de interface para:package
native
Beta Was this translation helpful? Give feedback.
All reactions