Requiring module question

[d.mach]

I require some modules in different scenes, like this for example:

-- mymodule.lua local mod={} local gfx={circle,rect} local createobj=function(group)      gfx.circle=display.newCircle(0,0,20)      gfx.rect=...      group:insert(gfx.circle)      group:insert(gfx.rect) end mod.gfx=gfx mod.createobj=createobj return mod

Now I have more than one scene or even other modules which are requiring this module above.

An example

the scene myscene1.lua is requiring the module AND another module which is also requiring the module above!

So the module above is required multiple times in one working scene (myscene1.lua)

Now when the scene is changing to another scene I want to free the memory correctly and I wonder if I have to keep track of all the places where the module was required and have to remove the graphics objects more than once (because the module was required on different places in the code)?

Or is it enough to delete the gfx table content once when the scene is changing?

[roaminggamer]

Modules In General

I think you asked this before, but…

1. When you first require a module it is loaded into memory and a reference is stored in a special table (globally visible, but you don’t normally touch it.)

2. The next time you require the same file, a reference to the table entry is returned instead.

All local references stored in that module will be there forever unless you clear them.

Your Code

The code you shared has some issues.

1. This does nothing:

   local gfx={circle,rect}

circle and rect are not defiend so that code is the same as this and does nothing useful:

local gfx={nil,nil}

2. Why two tables?  I don’t get the reason for the gfx table.  Does another function in the module need to know about ‘circle’ or ‘rect’?

In general, you do not keep file-level local references to objects in your module.  If you need the reference, return it from the builder.

3. The structure of your module is complicated for no reason.  This is better:

   local m = {} function m.createObj(group) group = group or display.currentStage – use current stage if group not passed in – local tmp = display.newCircle( group, 0, 0, 20 ) – build it right in the group; tmp is handle to circle – which allows you to further manipulate circle if needed – and tmp falls out of scope at end of function – so no need to ‘nil’ it. … end return m

[d.mach]

Thanks for the details.

Regarding the gfx table: I use it to remove all the graphics created inside this module from a scene file later at scene change.

[roaminggamer]

That is not a good practice.  Builder modules should be ignorant of the object instances they create.

1. Don’t keep references you don’ need.
2. Don’t destroy individual objects unless that is part of the game.  Instead, put objects in groups and destroy the group(s).  It is more efficient and safer.

PS - I sense you are really struggling with the concepts of scope and visiblity, as well as how Lua and Corona manage memory. 

It is too late now, but you should really have mastered these topics before working on a game. 

Not understanding these fundamental topics almost ensures you will have bugs, leaks, and performance issues.

Having said that, the best teacher is a mistake.  As long as you keep trying to understand why things fail and then tie that understanding back to a better practice you should be fine.

[d.mach]

Thanks!

I also use the gfx table to have access to manipulate the graphics created in the module.

BTW: I have found the memory problem. Can you please take a look at the last posts here (about the native.showAlert) and look if this is a known issue? https://forums.coronalabs.com/topic/74306-difference-in-system-memory-usage-on-device-and-simulator/page-2

[roaminggamer]

I saw the post, but I’m afraid i’m tapped out.  I’ll take one more peek, but I don’t guarantee I’ll have anything to contribute.

[d.mach]

I really appreciate all your help! Thanks a lot!

[roaminggamer]

Modules In General

I think you asked this before, but…

1. When you first require a module it is loaded into memory and a reference is stored in a special table (globally visible, but you don’t normally touch it.)

2. The next time you require the same file, a reference to the table entry is returned instead.

All local references stored in that module will be there forever unless you clear them.

Your Code

The code you shared has some issues.

1. This does nothing:

   local gfx={circle,rect}

circle and rect are not defiend so that code is the same as this and does nothing useful:

local gfx={nil,nil}

2. Why two tables?  I don’t get the reason for the gfx table.  Does another function in the module need to know about ‘circle’ or ‘rect’?

In general, you do not keep file-level local references to objects in your module.  If you need the reference, return it from the builder.

3. The structure of your module is complicated for no reason.  This is better:

   local m = {} function m.createObj(group) group = group or display.currentStage – use current stage if group not passed in – local tmp = display.newCircle( group, 0, 0, 20 ) – build it right in the group; tmp is handle to circle – which allows you to further manipulate circle if needed – and tmp falls out of scope at end of function – so no need to ‘nil’ it. … end return m

[d.mach]

Thanks for the details.

Regarding the gfx table: I use it to remove all the graphics created inside this module from a scene file later at scene change.

[roaminggamer]

That is not a good practice.  Builder modules should be ignorant of the object instances they create.

1. Don’t keep references you don’ need.
2. Don’t destroy individual objects unless that is part of the game.  Instead, put objects in groups and destroy the group(s).  It is more efficient and safer.

PS - I sense you are really struggling with the concepts of scope and visiblity, as well as how Lua and Corona manage memory. 

It is too late now, but you should really have mastered these topics before working on a game. 

Not understanding these fundamental topics almost ensures you will have bugs, leaks, and performance issues.

Having said that, the best teacher is a mistake.  As long as you keep trying to understand why things fail and then tie that understanding back to a better practice you should be fine.

[d.mach]

Thanks!

I also use the gfx table to have access to manipulate the graphics created in the module.

BTW: I have found the memory problem. Can you please take a look at the last posts here (about the native.showAlert) and look if this is a known issue? https://forums.coronalabs.com/topic/74306-difference-in-system-memory-usage-on-device-and-simulator/page-2

[roaminggamer]

I saw the post, but I’m afraid i’m tapped out.  I’ll take one more peek, but I don’t guarantee I’ll have anything to contribute.

[d.mach]

I really appreciate all your help! Thanks a lot!