HeroSquare Adventures 0.91 - Dungeon!

[Gnx]

New version again, see first post for changes

[Luca]

I'm looking forward to seeing how this project ends up. It has a good atmosphere to it, one that's as strange as it is original.

But I agree that the layering of things could be altered a little.

Edit: I really love how abstract the map is.

[arquivista]

I'm looking forward to seeing how this project ends up.

I believe that the project will end soon if the author don't stop be greedy! play or test it with only 3hp? right! after before having 100hp mobs playing still is synonym of fast death!

Anyway this time the changes were probably more cosmetical (didn't noticed much new than get the sword) than functional changes. I found the same related problems and real code problems as some "blocky" layered objects appear/dispappear out of time still there. Keep working on this GNX, still a lot to do.

[Luca]

We should make a mod for it where you get more HP and better swords. Perhaps levels and experience? I might make it!

[Gnx]

bump, probably the biggest content-update so far

[pygy]

For the drawing order, you may want to have a look at this snippet, based on this lib.

You'd have to adapt it in the following way: sort the sprites by y coordinates rather than z. You could use a z parameter to determine how far from the ground a flying object is, ie it's displayed y would be y+z, but, from a drawing priority view point, it would be located at y.

You could (should?) also adapt the library itself to
* quickly skip the initial hidden sprites by adapting the __index() function to be based on the y values rather than on the list index as it is now.
* iterate from a given node instead of starting from the head of the list (see iter()) .

[kikito]

For the drawing order, you may want to have a look at this snippet, based on this lib.

... he doesn't have that many elements to draw (20-30) so I'd go with something simpler: sorting all elements on every frame. Maybe it's less efficient, but it's just 6 LOC.

[Gnx]

For the drawing order, you may want to have a look at this snippet, based on this lib.

... he doesn't have that many elements to draw (20-30) so I'd go with something simpler: sorting all elements on every frame. Maybe it's less efficient, but it's just 6 LOC.

I think this is exactly what I need
The only problems after z-ordering are certain situations where faux perspective strains the visual coherency (where the drawing order depends on the relative y-values of the objects). I could write code for that too, but I'm not sure it would be worthwhile performance-wise.

[kikito]

... where the drawing order depends on the relative y-values of the objects). I could write code for that too, but I'm not sure it would be worthwhile performance-wise.

You mean this?

Code: Select all

-- used for sorting. This function returns true if entity1 should be drawn 'before/behind' entity2
function sortByYZ(entity1, entity2)
  if entity1.y < entity2.y then return true end -- first sort by y
  return entity1.z < entity2.z -- then sort by z
end
function love.draw()
  table.sort(entities, sortByYZ)
  for _,entity in ipairs(entities) do
    -- draw each entity
  end
end

[Robin]

Code: Select all

-- used for sorting. This function returns true if entity1 should be drawn 'before/behind' entity2
function sortByYZ(entity1, entity2)
  if entity1.y < entity2.y then return true end -- first sort by y
  return entity1.z < entity2.z -- then sort by z
end
function love.draw()
  table.sort(entities, sortByYZ)
  for _,entity in ipairs(entities) do
    -- draw each entity
  end
end

I think this doesn't do what you think it does. If entity1.y > entity2.y, it sorts by z rather than y. I think this would work better:

Code: Select all

function sortByYZ(entity1, entity2)
  if entity1.y ~= entity2.y then
    return entity1.y < entity2.y -- first sort by y
  else
    return entity1.z < entity2.z -- then sort by z
  end
end