[QUOTE=thelinx;33095917]Actually, you all can just submit any question you have about LÖVE to [url=http://answers.yahoo.com/]Yahoo! Answers[/url]™.
I hired a bunch of people overseas to help me with any issue you might have, so just ask away :)
Don't forget to click any ads you might see, the support people charge a [u]lot[/u].[/QUOTE]
You hired people overseas? Like, as in India? ...
[QUOTE=subenji99;33095987]It won't be reindexing then, so the problem will be how you're accessing the table.
You'll have to post some code.[/QUOTE]
[lua]
fireworkList = {};
firework = {};
firework.__index = firework
function firework.create(mouseX, startY)
local fire = {};
setmetatable (fire, firework)
fire.X = mouseX
fire.Y = startY
fire.limY = love.mouse.getY()
fire.dead = false
return fire
end
function firework:update()
self.Y = self.Y + firework_vy
if self.Y < self.limY then self.dead = true end -- kills the firework if less than limit
for i, firework in pairs(fireworkList) do
if self.dead then fireworkList[i] = nil end
end
end
function love.mousepressed()
table.insert(fireworkList, firework.create(love.mouse.getX(), 500))
end
function love.update()
for i = 1, #fireworkList do
fireworkList[i]:update()
end
end
-- I removed the love.draw and firework:draw functions as they're not relevant, the issue comes in at line 32 for fireworkList[i]:update()
[/lua]
that's the relevant parts, I've been moving things around and changing the table names all around to try and see if it works but doing that either makes it not work at all or still keeps the problem of only removing one firework and causing an error when there's two
-snip, incorrect-
Zard, you need to remove the dead fireworks after you've looped through all the updates
So, something like this:
[lua]
function love.update(dt) -- also, you should use dt to make sure it runs smoothly with weird framerates.
local deadFireworks = {}
for i = 1, #fireworkList do
fireworkList[i]:update(dt) -- passing the dt downwards
if fireworkList[i].dead then
deadFireworks[#deadFireworks + 1] = i -- add this to the sequence
end
end --updates have ended, let's clean up the mess
if #deadFireworks == 0 then return end -- if there is no mess to clean up, then we're done here
for i = #deadFireworks, 1 do -- loop backwards to avoid reordering issues
table.remove(fireworkList, deadFireworks[i])
end
end
[/lua]
[QUOTE=subenji99;33101594]You're not increasing i in your love.update for loop.[/QUOTE]
The for loop handles that automagically.
whoops, my mistake.
Im making a tile-based platform runner. Now what should I use for the map table? Numbers that link to a tileset array or put the tile data in the map itself?
The last one would give more dynamic updates, but I guess this slows everything..
Tile data that is unique per tile should be stored in the map itself. Tile data that is static among many tiles should be linked to using a reference to a table in the map.
When I say linked to using a reference to a table, I mean you should do
[lua]images = {
{love.whateverfunctionloadsimages(pathOfTile0)}, -- images are stored in tables, such that images[0][0] accesses real image data
{love.wahteverfunctionloadsimages(pathOfTile1)} -- putting a single variable in a table allows a single variable to be referenced instead of copied
}[/lua]
Tables in Lua are always unique while any other variables get copied every time you assign a different variable to them. For example,
[lua]local x = 5
local y = x -- y is a copy of x i.e. if you change x, y does not change
local a = {5}
local b = a -- b is an alias of a i.e. if you change a[0], b[0] changes too[/lua]
Thus, your map should be structured somewhat like this if we use the above images table
[lua]map = {
{{image = images[0]}, {image = images[1], onWalkedOver = killPlayer}},
{{image = images[1]}, {image = images[0]}}
}
-- Accesses a tile's image data (the tile at x = 1, y = 1 specifically)
map[1][1].image[0][/lua]
The whole reason I would use references instead of copies of data is that references ensure that if the data is changed in one place, it is changed in all places.
For an example of why that is good, you can change images[0][0] and all tiles with that image get affected instantly.
[b]Edit:[/b] Also, if your tiles need to contain more data than just an image (such as collision detection info), the image references could be re-imagined as tile references.
I'm late teacher :( Please don't hit me as I only started today.
The dog ate my homework, the cat pissed on my computer and I chopped my own hands off so I couldn't work. :v:
[video=youtube;59FJVK3h91g]http://www.youtube.com/watch?v=59FJVK3h91g[/video]
Not done yet, this is hard.
[QUOTE=WiZzArD;33106159]-snipper mcsnip-[/QUOTE]
That would be a good thing if all data was static, but the maps and tiles are loaded from external XML files.
[QUOTE]The whole reason I would use references instead of copies of data is that references ensure that if the data is changed in one place, it is changed in all places.[/QUOTE]
From this, can I assume that it doesn't give a big difference in speed?
[b]Edit:[/b]
This is an example of a tile:
[HTML]
<tile id="0">
<string key="name">Air</string>
<image key="img">img/tiles/void.png</image>
<table key="collide">
<bool key="left">false</bool>
<bool key="top">false</bool>
<bool key="right">false</bool>
<bool key="bottom">false</bool>
</table>
</tile>
[/HTML]
The map data is just a large string of 1, 2, 3, etc.. depending on the tile at that position.
Now why I was asking this is because I also want to make it able to add custom event listeners to the tiles (like onUpdate) and if I put the tile data in the map array, the events would have more options like storing per-tile data. The only downside on this and the reason I asked this is that I dont know if this has a noticable impact on performance.
Seeking some help with adding 'explosion'.
I'm new to LUA..
If anyone can just help me implent some easy explosion mechanics, then I can maybe finish this today!
[url]http://pastebin.com/kDj8dX3D[/url] <-- code.
Alright so Im assuming I misspelled something somewhere, maybe. Or Im just doing something really stupid or forgetting something really simple.
Im trying to create a 'firework'. Which is just going to be a circle that flys up the screen and then the particles are created when it gets to the mouse point.
When I call 'fireworkList[i]:think(dt)' and 'fireworkList[i]:draw(dt)' it says that 'think' and 'draw' methods are nil values. So Im assuming that means those methods dont exist. They do exist. But what Im thinking is that the fireworkList isnt actually full of fireworks, which is why it cant find the methods. I've looked through the code so many times but I cant find the problem.
Any help would be much appreciated.
[url]http://pastebin.com/4d48MQB6[/url]
[QUOTE=Darkest_97;33117920]Alright so Im assuming I misspelled something somewhere, maybe. Or Im just doing something really stupid or forgetting something really simple.
Im trying to create a 'firework'. Which is just going to be a circle that flys up the screen and then the particles are created when it gets to the mouse point.
When I call 'fireworkList[i]:think(dt)' and 'fireworkList[i]:draw(dt)' it says that 'think' and 'draw' methods are nil values. So Im assuming that means those methods dont exist. They do exist. But what Im thinking is that the fireworkList isnt actually full of fireworks, which is why it cant find the methods. I've looked through the code so many times but I cant find the problem.
Any help would be much appreciated.
[url]http://pastebin.com/4d48MQB6[/url][/QUOTE]
only 1 underscore on your index metamethod for Firework.
line 9:
[lua]Firework._index = Firework[/lua]
[QUOTE=subenji99;33118038]only 1 underscore on your index metamethod for Firework.
line 9:
[lua]Firework._index = Firework[/lua][/QUOTE]
Oh damnit I didnt even realize the particles one had 2 underscores. Thanks so much.
Now to find out why they dont draw, move, or do anything! :eng101:
[QUOTE=MitchvW;33117388]Seeking some help with adding 'explosion'.
I'm new to LUA..
If anyone can just help me implent some easy explosion mechanics, then I can maybe finish this today!
[url]http://pastebin.com/kDj8dX3D[/url] <-- code.[/QUOTE]
The simple solution I used was to create a random amount of particles that each got a random x and y velocity value and size, but the position was the current firework's location. Because I felt it looked better though, I kept them all the same colour (almost, put some randomness in) from a single firework.
Just note that you may get a "square" randomness pattern with this method, and to fix that you have to look into vector mathematics to "normalise" your velocities. But that's for your own exploration. :v:
Figured it would be fun to somewhat replicate the system in RollerCoaster Tycoon 3.
I pretty much ignored every single one of the rules (although I am using Löve), sorry!
Only has 4 firework types at the moment (with some colour variations), but I'll probably add some more and improve the ones I already have at some point.
[video=youtube;FQMCQQfgzB8]http://www.youtube.com/watch?v=FQMCQQfgzB8[/video]
Gwilty has got stuck on his assignment and needs some hands on with me. Extended until Wednesday.
"Hands on"
[QUOTE=garry;33120327]Gwilty has got stuck on his assignment and needs some hands on with me. Extended until Wednesday.[/QUOTE]
Deja vu
It's still pretty basic, but it's progress.
[img]http://puu.sh/86tu[/img]
(ignore the failed positioning of the debug print)
No sounds yet, fireworks have particle trails and the explosions are all random colors. Particles use points for drawing, I'll probably change that to something fancier later. Having glowing particles would be neat. It's not very optimized either, 10 fireworks are enough to make it choppy.
Source code still [url=https://bitbucket.org/pollyzoid/fireworks/src]here[/url].
Ive just got save files to work, but Im still thinking about how to make it binary... Any ideas?
[QUOTE=raBBish;33121334]It's still pretty basic, but it's progress.
[img]http://puu.sh/86tu[/img]
(ignore the failed positioning of the debug print)
No sounds yet, fireworks have particle trails and the explosions are all random colors. Particles use points for drawing, I'll probably change that to something fancier later. Having glowing particles would be neat. It's not very optimized either, 10 fireworks are enough to make it choppy.
Source code still [url=https://bitbucket.org/pollyzoid/fireworks/src]here[/url].[/QUOTE]
How did you get the FPS to show on the screen?
[QUOTE=All0utWar;33123926]How did you get the FPS to show on the screen?[/QUOTE]
He probably did:
love.graphics.print("FPS: "..love.timer.getFPS(), x, y)
[QUOTE=All0utWar;33123926]How did you get the FPS to show on the screen?[/QUOTE]
love.timer.getFPS()
[QUOTE=BlkDucky;33123952]He probably did:
love.graphics.print("FPS: "..love.timer.getFPS(), x, y)[/QUOTE]
No, it wasn't that. I was tired and stupid and didn't research so I wrote my own that takes the inverse of average dt over ten frames.
[lua]local _dts = {}
local _lastdt = 1
function love.update( dt )
if #_dts == 10 then
_lastdt = (_dts[1] + _dts[2] + _dts[3] + _dts[4] + _dts[5] + _dts[6] + _dts[7] + _dts[8] + _dts[9] + _dts[10])/10
_dts = {}
end
_dts[#_dts + 1] = dt
--
end
-- later
g.print( " fps: " .. math.ceil(1/_lastdt), 10, 10 )[/lua]
But you should use getFPS.
[QUOTE=Map in a box;33124324]Whats wrong with 1/dt?[/QUOTE]
It changes every frame, so it's kinda annoying to read.
Whats wrong with 1/dt?
He used 1/dt
[lua]g.print( " fps: " .. math.ceil(1/_lastdt), 10, 10 )[/lua]
just he added up the last 10 results and took an average first for somewhat better reliability (but not as much as love.timer.getFPS() :v:)
From what I found, using love.timer.getFPS() vs math.floor( 1/dt + 0.5 ) results in about a 300 frame difference for me.
Then again that's only from 700 to 1000, so idk, it's not a big deal, I don't think. They do explicitly state using getFPS() drops your fps, though, from what I recall.
[editline]4th November 2011[/editline]
Yep: [url]http://love2d.org/wiki/love.timer.getFPS[/url]
[quote=LOVE wiki]getFPS() is known for poor performance, ironically reducing the FPS its designed to measure.[/quote]
Personally I'd have gone with something like
[lua]local dtTbl = { fps = 0, total = 0, count = 0 }
function love.update(dt)
if dtTbl.total >= 1 then
dtTbl.fps = dtTbl.count
dtTbl.total = 0
dtTbl.count = 0
end
dtTbl.total = dtTbl.total + dt
--other update code
end
function love.draw()
dtTbl.count = dtTbl.count + 1
--other draw code, including displaying fps
end[/lua]
Edit - just tested this, and it gave comparable results to love.timer.getFPS() (which wasn't showing any kind of lag using vs not)
[QUOTE=amcfaggot;33125415]From what I found, using love.timer.getFPS() vs math.floor( 1/dt + 0.5 ) results in about a 300 frame difference for me.
Then again that's only from 700 to 1000, so idk, it's not a big deal, I don't think. They do explicitly state using getFPS() drops your fps, though, from what I recall.
[editline]4th November 2011[/editline]
Yep: [url]http://love2d.org/wiki/love.timer.getFPS[/url][/QUOTE]
I am not sure how love.timer.getFPS() will lower your framerate, literally the only thing it does is return the fps variable, which is recorded regardless of whether getFPS is called or not.
[cpp]
double Timer::getFPS() const
{
return fps;
}
int w_getFPS(lua_State * L)
{
lua_pushnumber(L, instance->getFPS());
return 1;
}
[/cpp]
Sorry, you need to Log In to post a reply to this thread.
