PÄSSION: object-oriented LÖVE

[kikito]

Thanks guys.

It seems it is a local problem in my computer, then. I'll see if I can find the issue.

@Robin: Thanks for your comments. I'll change those asserts to errors. Regarding your other comment, I'm still thinking about modelling floors properly - the current code is just a placeholder. In case you are interested, my current impression is that I'll probably end up using a "feet" shape sensor, for walking over scenery, separated from the "body" shape, that will handle walls/bullets/enemies/powerups. The feet sensor isn't likely to be squared (I'm thinking either an inverted triangle or a circle).

[kikito]

Quick in-between holidays update.

I've not been able to solve why "drag-n-dropping to the love.exe" file didn't work any more - I've bypassed the problem entirely by including love.exe on my PATH environment and making:

Code: Select all

cd myproject
love .

on a DOS prompt. It is actually faster than drag-and-dropping, so I'm happy.

I continue tweaking the engine and the "demo platformer" that I was building with it.

On this new version,

• The player's feet is represented by an inverted trapezoid (nearly a triangle) instead of a box. I made the change so I could use irregular terrain, instead of just boxes.
• I can create polygonal platforms
• Contact points now also show their normals
• I've started my own gui (yep, another one). For now it just shows labels and static text (no fancy interactive stuff yet). But the labels are "Actors", too, so they inherit interesting properties - like an update function. And it is easily customizable in one line - I tried it to feel like CSS.
• I've added a small tweak to MiddleClass so it is easier to create attribute getters and setters. I feel I'll be using this a lot when developing the gui further.

On the next release I'll concentrate in making the walls interactions more interesting, and also the ramp/slide ones. I'll try to add some collectibles and trackle Actor destructions (for now all actors are "inmortal"). I might add gui.Button class, too.

I'll be on holidays and without internet for the next week, but please do comment! Your comments definitively increase the code quality!

Happy new year!

[bartbes]

I think your error might be rude's epic unicode hack failing, could you tell the path?

And, of course, a happy new year to you!

[kikito]

Hi Bartbes,

I doubt it is a Unicode-related issue. My paths are quite humble:

Code: Select all

D:\LOVE\test

I've got the love.exe inside the LOVE directory, and I've got one folder there for every project I do. It works when I use the windows console, but not when I drag-n-drop the folder to the exe. If there's any offending code, it must be in the routines that handle "drag-and-droppingness". And don't rule out an problem in my own PC old and cranky windows (more than a year without a reinstall...)

But thanks for replying so quickly!

[Robin]

If there's any offending code, it must be in the routines that handle "drag-and-droppingness".

AFAIK, on Windows, dragging and dropping files on apps is handled by the Windows Shell, which then runs the application with the file as single argument.

[kikito]

After some time, an update!

I got a bit tired of fighting with Box2D so I decided to go for something completely different: a GUI!

Screenshot!

PÄSSION GUI Demo screenshot

PÄSSION GUI Demo v1.png (21.1 KiB) Viewed 3086 times

For now my GUI is only able to do 3 things:

• Pannels, which are just a rectangle with border and background properties. Also, pannels can have a "father" and "children" pannels (the children's coordinates are "local" to the parent, which makes positioning stuff easier - you move the parent, and the children move too). Finally, there's an (expensive) way of rendering rounded corners, with borders.
• Labels, which are Pannels that allow text to be introduced on them (with properties such as font type, color and size)
• Buttons, which are labels that interact with the mouse. A button can detect when the mouse is over it, when it leaves it, and then it is "pressed" and "clicked" (click = press + release while still over the button)

I'm particularly fond of the buttons because they work with internal states (MouseOut, MouseOver & Pressed) and react differently to the mouse depending on their status.

The "callbacks" are able to execute any kind of code. For example, one could make a button emit a sound when the mouse goes over it. I decided to stick with what I knew and just changed text & colors.

I've also started to create a "Stateful" game. Not very completed yet, since it only has one state. The code for this is on the Game.lua file. But the Game object only has one state, for now.

One warning: after some playing around, the application starts going slowly, and on Ubuntu I got the following error:

Code: Select all

TrueTypeFont Loading vm->error: FT_Get_Glyph failed.
Segmentation fault

No idea why this happens. I'm using the latest ubuntu version from builds.

Please feel free to play around changing the colors or emiting some sounds in the onMouseOver function.

EDIT: removed pgdv1.love since I don't want to break anyone's computer. Please try pgdv2.love instead (further on the forum)

[kalle2990]

I had some struggling with this before too, it's actually very simple
Somewhere in your code, there is a loadFont (directly used, or indirectly by another function) which is ran in update or draw causing LÖVE to take up much more RAM than usual, and crash.

[kikito]

Hi Kalle, thanks for the feedback!

Here's the complete code I have for "setting up the font when drawing" (this is inside passion/gui/Label.rb)

Code: Select all

if(font ~= nil and fontSize ~= nil) then love.graphics.setFont(font, fontSize)
elseif(fontSize ~= nil) then
  love.graphics.setFont(fontSize)
  font = love.graphics.getFont()
end

Let me explain: Labels have two parameters, font & fontSize. If both of them are filled up, love.graphics.setFont is called with them.

Now, if font isn't set, but fontSize is, I want to use the default font, with the new size. So I do love.graphics.setFont(size), and then obtain the font with getFont.

It is quite straightforward... but I don't know, maybe getFont() is creating one font object each time it is called?

... I've tried giving a look at the source code, but was not able to navigate to where the setFont / getFont functions are defined. And there's what looks like a new module (love.font?).

I'll try to make a little "default font manager" so I don't have to call getFont every time, but just the first time it is needed. But I'm open to other suggestions.

[kalle2990]

I did some small experiment, removing the line "love.graphics.setFont(fontSize)". It don't take up all the RAM at that point, it seems like just changing the size is taking as much RAM as a whole new font... You should try making a quick new function that does something (checks if there is a font that has been created, which has been put in a table, if there is one use the table font, otherwise create a new one and put in a table), and using it instead.

EDIT: Updated the un-complete code example, this version is tested and it works

Example:

Code: Select all

createdFonts = {}
currentFont = love._vera_ttf

function setFont(fnt, size)
   local size = (type(fnt) == "number") and fnt or size
   local fnt = (type(fnt) == "number") and currentFont or fnt
   fnt = (fnt ~= nil) and fnt or currentFont
   local position = 0
   for i,v in pairs(createdFonts) do
      if v[1] == fnt and v[2] == size then
         position = i
      end
   end
   if position == 0 then
      local font = love.graphics.newFont(fnt, size)
      love.graphics.setFont(font)
      local t = {fnt, size, font}
      table.insert(createdFonts, t)
   else
      love.graphics.setFont(createdFonts[position][3])
   end
   currentFont = fnt
end

[bartbes]

Yes, changing size creates a whole new font.