1. Anders Ruud
  2. love
  3. Issues


Issue #766 wontfix

Constructors accepting files

created an issue

I'mma propose that functions accept files where possible, and by files I mean filepaths, Files and FileData.

I've already proposed that newCursor (#741) and setIcon (#668) do this, but still left is newMesh, newSpriteBatch and newParticleSystem.

The reasons why:

  • It's consistent. Other constructors accept files, why don't these? newImage doesn't need to accept files, it could accept ImageData instead, likewise with static Sources and SoundData.
  • It's useful and nice. If you want to create an object from a file, and don't have a use for the file anywhere else, why do you need to create another intermediate object? It would make the code more concise, and more... I'm not sure how to articulate it... more "you don't need to think about things other than what you're trying to do". For example, why does a lover need to know about ImageData just to set the icon?

A possible objection to this is that performance wouldn't be as good when used like this, since it's recreating Images and possibly reading from disk.

To this I would say:

  • I think this sort of thing already happens with static Sources. I assume it's faster and more memory efficient to create multiple static Sources from SoundData, which you can do, but you can also create static Sources from files.
  • I'm assuming it probably doesn't matter. If it ever does seriously affect performance, of course things can be optimised by creating intermediate objects, but for all the other times it's probably just nicer to create objects straight from filepaths.

Comments (10)

  1. Alex Szpakowski

    It's consistent. Other constructors accept files, why don't these? newImage doesn't need to accept files, it could accept ImageData instead, likewise with static Sources and SoundData.

    The constructors which accept files are for objects which can represent what the file is. For example, an Image object accepts image files. A SoundData accepts sound files. In the future a Mesh may accept a mesh file because such things exist.

    One reason why a Mesh object does not accept an image file(path) is because it is not an image. Likewise for SpriteBatches and ParticleSystems. They can use LÖVE image objects, but they aren't designed for creating/loading those.

    I also don't like introducing many versions of a function just for the sake of saving a line in a circumstance that isn't even very intuitive. :)

    With the current Cursor API it's a little more ambiguous because not all Cursor objects are user-defined images. setIcon is not an object constructor, so it's consistent not to have it accept files (although I haven't made up my mind if it should or not.)

  2. hahawoo reporter
    • changed status to open

    Ah, but what about newImageFont?

    It accepts image files, which isn't what a Font represents.

    Also to note, while ImageData and SoundData can represent images and sounds, Images and Sources have additional state which (as far as I know) aren't represented in files.

    I'm not really sure what my proposal is right now, other than "things should be consistent". :P

  3. hahawoo reporter

    Hmm, but what's the difference between, say, newImageFont and newMesh?

    They both:

    • Accept images.
    • Need additional data (glyphs or vertices).

    I guess a formatted image represents an image font, but only part of it. But in this sense, perhaps an image represent represents part of a Mesh too?

  4. Alex Szpakowski

    A bitmap font is an image. A mesh is a collection of vertices assembled into polygon(s). Meshes can be textured or untextured, but it's not a defining feature of a mesh.

    In most 3D games, textured meshes tend to use multiple textures to represent different things (i.e. normal maps, specular maps, etc.) rather than just a single one.

  5. hahawoo reporter

    I see, thanks for the info! :)

    What about ImageFonts and SpriteBatches then?

    They both require an image, and need extra data to be useful.

    There are quite a few differences between them, such as if there was a "sprite batch file format" and newSpriteBatch could also accept an image filepath it would be ambiguous, like newSpriteBatch('image.png') and newSpriteBatch('spritebatch.sb'), but due to the necessary second argument in newImageFont this wouldn't be the case if there was an accepted image font format.

    But, why does one accept image files and the other not? (Or did I just mention the reason? :P)

  6. Alex Szpakowski

    A SpriteBatch isn't an Image, it's just information stored efficiently on the GPU about where an Image will be drawn (and you can even change the image it will use with SpriteBatch:setImage). A SpriteBatch is sort of a specialized Mesh with a higher level API.

  7. hahawoo reporter

    Hmmmm, I think I finally get it now, thanks!

    In the case of an ImageFont or a Cursor or a Source etc., the object is made from the file, the file is part of the object, whereas with SpriteBatches and Meshes etc., the image object is referenced, an interchangeable (and optional in the case of Meshes) part.

  8. Log in to comment